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ABSTRACT 

The    Joint   Deployment    System     (JDS)    forms   the    junction 
among    deliberate    planning,     time-sensitive   planning,    and   the 
deployment   cf   forces.      The    WWMCCS   Intercomputer    Network 
(WIN)     supplies    the    necessary   interconnectivity  among   -.he 
joint    deployment   community    computer   systems.      In    January 
1982,    the   wkmccs   Information   System    (HIS)    modernization 
program    was   launched    with  objectives    including  -he    mcderni- 
zaticn   cf   HWMCCCS   hardware    and    software    and   the    transfer 
from    the    present    WWMCCS    network    system   to    the   Defense   Data 
Network     (DDN).       Because   of    proven   WIN   unreliability,    the   JDS 
required    site-unique    software   development    to    supplement 
present    WIN    software. 

Individualized    application    software,    integrated    with   the 
improved    network   reliability   and    survivability  cf    the   DEN, 
will    enhance   the   present    C3    system.      This    thesis    demons- 
trates  that    the    total   implementation    of    the    WIS    involves 
additional   modifications    in    site-unique    applications,    stand- 
ardized   procedures    for  software    development,    updated 
hardware    technology,    and    a    multi-level    security   system. 
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I.    INTRODUCTION 

A.       PDBPOSE 

In   the   late    seventies  time-frame,    the    Joint    Deployment 
Agency    (JEA)    experienced   an  satis  factory    WWMCCS    Intercomputer 
Network     (WIN)    reliability   for   large    data    transfers    tc   remote 
sites.      The    BWHCCS    Information   System    (WIS)    modernization 
program    addresses  the  WIN   deficiency    issues   of  power 
supplies   and   multi-level    security  and    proposes  changes    in 
the    WWMCCS   network    tc  allow    greater    interconnect iv it y   among 
sites. 

This   thesis    attempts    to    assess   the   WIS    modernization 
impact    en    large    software    systems    in    the    WWMCCS   community,    in 
particular,    the    Joint   Deployment    System     (JDS).      Specific 
deficiencies  in    areas   of   hardware   and   software,    surviv- 
ability,   and  management    will   be   addressed   and   planned 
improvements  analyzed.      The    modernization    program    should 
improve    computer   int ereennectivity   among   the    joint    deploy- 
ment   community    in  the   future,    but   the    command-unique 
software    and  WWMCCS    standard   software    modifications    will 
provide    the    operational   reliability    necessary   for   operations 
in    the   interim.       With  the   conglomeration    of   subnetworks    into 
the    Defense    Data    Network   during    the    1983-1986   time-frame, 
plus    the    future    WIS    support    of   these    command-unique    software 
applications  and   the    improved  WWMCCS    Network,    the    joint 
deployment    community    may    experience   a    more   reliable   system 
for    cemputer  resource   sharing. 


E.        HILITARY   C3     NETWORK 

The    Worldwide   Military    Command  and  Control  System 
(WWMCCS)    cf   the    United  States  centers   around   the    needs    of 
the    National  Command    Authority    (NCA) .       A   Command,    Centre! 
and   Communications    (C3)    process    can    be    considered   an    uncer- 
tainty  reducing    technique   which   aids    the   commander    in   the 
control    of    forces.       &   good    C3  system    must    permit    the    secure 
and   timely    flow    cf    information   to   points   both   inside    and 
outside   the    Department  of   Defense    (DOD)  .      This   flow    must 
exist   during  all  scenarios    --   day-to-day   activities,    crises, 
conventional  conflict,   and    nuclear   war.      The   C3    system    is   a 
major   ingredient   to    the   U.S.    national   goal    of   deterrence   cf 
war.      [ Ref.    1:    p.    53 ] 

Using   WWMCCS,    the   NCA  communicates   its    desires    for 
deployment   of  military  forces  to   the   Joint   Chiefs   of    Staff 
(JCS).      In    short,    the   JCS   mission  can    be    defined    as    the 
execution   of  national   decisions.      This    mission   is    supported 
by   various   communications   networks   and   command  and   control 
systetrs,    one  of    the    nest   central   being    the   Joint    Deployment 
System    (JCS)    which    provides    a   bridge    between   the    deliberate 
planning    process   and    time-sensitive    planning    and    execution. 
Connectivity  for   these  systems   is    provided    by   the    National 
Military    Command   System     (NMCS)    which    consists   of    three 
command    centers:      the   National    Military   Command    Center 
(NMCC)  ,    the    Alternate  National  Military    Command   Center 
(ANMCC)  ,    and  the   National  Emergency    Airborne    Command    Pest 
(NEACP)  .      Also    included    in    the    NMCS    are    the    various 
personnel   and  equipment    necessary    for    adequate   control    cf 
forces.      [Ref.    2:   p.    36] 

The    Defense    Communications   System    (DCS)     is   the    founda- 
tion   for    worldwide    communications   during    both   peacetime    and 
crisis   situations.       The    DCS    covers   the    United   States, 
Europe,    and    the    Pacific   area    with   networks    such    as    the 


Automated   Vcice    Network    (AUTOVON)  ,   the    Automated    Secure 
Voice    Network(AUTOSEVCCOM)  ,     and   the    Automated  Digital 
Network    (AUTODIN).       WWMCCS    was   astablished    in    1962    and 
supports    the  command    functions   of   the    NCA    by    supplying 
information    through    an  online   data   base    system.       Although 
communications    is  a    fundamental   aspect   of   a   C3  system, 
simply   having  gocd    communications    does   not    equate    to    an 
adequate    conmand,    control,    and   communications   system.      The 
proper    balance    of   command  and  control   and    communications,    in 
union    with    fcrces,    results    in   maximum    force   effectiveness. 
[RQf.    3:    p.    40] 

C.       WWMCCS 

WWMCCS    evolved    in  the  early    1960' s   from   a   loosely    knit 
conglcmeraticn    of   about    158    computer    systems,    using    30 
different   software    systems,    and   operating    at    81    locations: 
all    serving   the    JCS,    Unified  and   Specified    commands,    and   the 
Service    cemmands.      The  majority    of   these    systems    were    devel- 
oped   independently,     consequently    the    lack    of 
intercperability    within   the    total   system    proved    detrimental 
to    its   meeting    the    NCA  requirements    for    intercommunications 
among    si::es.      As   the    concepts   of    C3    grew,    additional 
requirements  were   demanded    of   the   system;    these    requirements 
were    net    sporadically,    and    by    1970,    there    was    an    evident 
need    for    a    WWMCCS   modernization   effort.       In   June    of    1970, 
the    WWMCCS    Automated    Data   Processing     (ADP)     Program    was 
initiated    tc   improve    WWMCCS    support.       The    program's    goals 
included : 

(1)  reduction   of    cost   through   standardized    hardware 
and   software 

(2)  development    of    a   viable    Data    Base   Management 
System     (DBMS)    for  data    retrieval 

(3)  standardization    of   data    formats 
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(4)    centralization    of   1aanag9ma.1t   activities   [Sef.    U: 
P.    2] 

Prior   to  this   effort,    the   WWMCCS    program    had   no    central 
authority    for   its   budgeting    or   management.       Numerous   organi- 
zations  were  responsible   for  the    various   aspects    of    the 
program;    for  instance,   the    WWMCCS  Council   provided   policy 
guidance    for  development    and  operation   of   the   system;    the 
JCS    evaluated   WWMCCS*    overall  effectiveness;    various 
Assistant   Secretaries  of    Defense    provided   advice    on   system 
design   and    development,    warning    and    intelligence    matters, 
and    AEP   procurements;    and   each   service   was   responsible    for 
fundirg    its    eguipment  acquisition  and   software   development. 
The    WWMCCS    System   Engineering  Office     (WSEO)  ,    a   separate 
organization  in    the    Cefense    Communications    Agency     (DCA) ,    was 
organized    in  the   raid    1970's    to    coordinate    the   general   system 
engineering   of    WWMCCS.      One    of   the  biggest,    disadvantages    to 
the    WWMCCS   management   structure    was    that,   the    Director.-    CC?, 
also    Director,    WWMCCS   Engineering,    reported   to   two   organiza- 
tions:     the    Assistant   Secretary    of  Defense    (C3I)     for 
organization  and   technical    matters   and   the   chairman   cf    the 
JCS    for    doctrine,    operational   policies,    and   validation    of 
requirements.      This,    compounded    with    the    fact   that   the 
Director,    DCA,    had    no  authority    for   the    budgeting    or    manage- 
ment   of    the    WWMCCS    program,    precluded   the   successful 
coordination  of    WWMCCS  ADP    development   efforts.      [Ret-    5:    p. 

8] 

The    WWMCCS    ADP    Program    also    outlined    a    set   of    well- 
defined    reguirements    which    included    the    capability    to 
process   large  amounts  of   data  within    a  reasonable   time, 
reliability    greater    than    99%,    user  and   maintenance    friendli- 
ness,   and   small    physical   space   and  personnel    requirements. 
[Ref.    6:    p.    22] 
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The    WWMCCS    functions    which    support    related   Hissicns    are 
grouped   to   allow   each   family   of    functions   to    be    indepen- 
dently  defined   and    i nplemen ted.      Interfaces   among   the 
functional   families    are    well    defined.      One    of.    the    basics    of 
the    WWMCCS   architecture   is    the   concept   of    four   distinct 
functional   families    which  support   the   NC&,    JCS,    and   Unified 
and    Specified  Commands.      They  are: 

(1)  Resource   and   Unit   Monitoring    (RUM) 

(2)  Conventional   Planning   and   Execution     (CPE) 

(3)  Nuclear    Flanning  and    Execution     (NPE) 

(4)  Tactical    Warning/Attack   Assessment   and   Space 
Defense     (TW/SA  and    SD)    [  Ref .    7:    p.    H-';] 

In   addition,    WWMCCS    ADP    is    divided   into    three   catego- 
ries.     Category    A    includes    the    WWMCCS    standard  software,    the 
backbone    of    WWMCCS    ACP  which   principally   supports   -.he 
command   and   control    requirements.      Category    8  is    that   soft- 
ware   which   is   unique    to    a  particular    activity.      And    Category 
C   encompasses  the   newly    emerging    systems.      [Sef.    8:    p.    2] 

As    WWMCCS   grew,    utilization    of   the   WWMCCS   Intercomputer 
Network    (WIN)    increased.      The   network    was    initiated    as    a 
prototype   at  three    sites    and    from    1977   to    1983   the    number   of 
WIN    sites    jumped    fron   six   to    twenty-three,    with    future    plans 
eventually    including    all   WWMCCS    srtes.      Commonly    used    func- 
tions  include: 

(1)  maintenance  of    status    and    location  of    forces   and 
resources 

(2)  planning    for    force   mobilization    and    deployments 

(3)  preparation   of    the    Single    Integrated   Operations 
Plan    (SIO?) 

(4)  estimating  and    monitoring   Navy    fleet    fuel 
consumption 

(5)  assisting   in    preparation    and   processing   of 
AUTODIN    messages   [Ref.    9:    p.    5] 
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The    utilization    cf  the    Joint    Deployment   System     (JDS) 
contributed   to    the    increased  activity    on   the   WWMCCS    network. 
As   a    primary  function,   the    JDS   maintains   Time-Phased   Fores 
Deployment    Data     (TPFDD)     files   for   specific    Opera-ion    Plans 
(OPLANs)    outlining    the  supported   commander's   concept   of 
operations   and    requirements.      [  Hef .    10:    ;?.    11]  Prior    to 
additional   software    development,    these   files    were   sent    to 
WIN    subscribers    in   their   entirety   to    initiate   JCS    exercises. 
As    the    TFFDD  files    were    updated    through©  it    tha   exercise,    the 
entire    file    was    agair   sent    to  ail    asers.      These   large   data 
transfers,    coupled    with   an    overall  increase   in   WIN    usage, 
placed   a    fcurden    en    network,    componerts  and    host  processors, 
causing    WIN    performance  to    reach    an    unsatisfactory    level. 
Particular    site-unique  development  included   the   JDS    Remote 
User's   Package    (RUP)  ,   discussed    in  Chapter    3. 

A   new   surfacing    problem    was    the    lack    of   a   Multi-Level 
Security     (MLS)     systerr.      A   MLS   system    allows   users    with 
varying   security   clearances    to   simultaneously   share   computer 
equipment    with    access  to   various    software    allowed   on    a 
case-fcy-case  security   check.      One   theory    for    implementing   a 
MLS    system    is  the   usage   of    rings   cf    protective  organization 
for    the   hardware.      Here,    the   operating   system   is    segmented 
into    N-rings,    with    N    greater   than   two.       The   inner-most    ring 
will    te    occupied    by    the    core,    or    kernel,    of   the    operating 
system.      The  system    software  and    security   processes    will    be 
run    here;    for  instance,    validation   of    passwords    and    data 
access   reguests.      The   resource   allocation    software   should 
reside    in    a    seperate    ring  for   scheduling   of   tasks    and 
computer    resources.       The    outer   rings    are   available   to   the 
users   for   processing    application   programs.      Routines    in   Ring 
1  i*     have    access    to    Rings    '  i'    and    all    rings    greater    but    can 
only    access    more   inner  rings   through    procedure   calls,    thus 
affording  the   proper    security  check    opportunity.      The    rings 
cf    prctecticn  secure    sensitive   software    and   data    and   also 
act    as   firewalls   against   user   damage.      [Ref.    11:    p.    540] 
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It    is   interesting   to   note    that  in   the   mid-1960's   -.h? 
Massachusetts   Institute  of    Technology,    Bell   Telephone 
Laboratories,   and   the  computer   department   of    the    General 
Electric    (GE)    Company   developed    sne   of  the    first    operating 
systeits   tc   employ  rings   of    protection,    the    Multiplexed 
Information    and    Computing  System    (MOLTICS)  .      The   original 
MULTICS    was   installed  on    a    G3645,    later    a    Honeywell 
Information    System     (HIS}    64  5    computer,    and    in    1973,    replaced 
by   the    HIS    6180.      The   HIS   6  130    supports    eight    rings    cf 
protection:      the   operating    system   uses   Rings    0-3;    Rings   4-7 
are    available   tc   the    users*,      [Ref.    11:    p.    535]  With    no    MLS 
system,    all    machines,   terminals,    and    personnel  on   the   WIN 
must    te    cleared    to    the  highest    level    being    utilized. 
[Ref-    12:    p.   7] 

Cther   problems    included    the    lack,    of   a    long-range    plan 
for    WWMCCS/WIN    development    and    the    sarly    1960    Honeywell 
architecture   which    is  not  tha  state-of-the-art    for    an   online 
guery   and   response    system. 

A    misconception    was  also   prevalent   concerning   WWMCCS    — 
that    it    would  provide   communications    between    the    President 
and    the    foxhole.      This   was    never    the    design    intention    of 
WWMCCS;    however,    what   was   desired   was    a    communications 
network    for    several   command    echelons    and   a    reliable    military 
command   and   control    system    connecting   the   NCA   to    the 
executing   commanders.     [Ref.    1:    p.   40] 

Although   the   reliability    of    the    WWMCCS    Intercomputer 
Network    (WIN)    had   fallen   below   a    satisfactory  level,    the 
WWMCCS    AEF    sites    utilized  the  on-site    Honeywell   computer 
equipment   tc  develop    software  applications   for   unique 
requirements.      By  the   mid    1970*s,    there    was    a   great    depen- 
dency  en    WWMCCS    ADP    for   day-to-day  operations   and 
crisis/exercise    support    and   the   need    for   a   reliable   computer 
network    became    obvious.      [Ref.    12:    p.    7] 
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I*-     W1HCCS    INFORMATION    SYSTEH 

fl.        BflCKGBOUND 

Ie    November    1931  F   th€i  Deputy   Secretary   of   Defense 
decided   the    HHMCCS    Information   System    (WIS)    modernization 
plan    needed   a   focal    point  for  coordination    to   receive   pclicy 
and    guidance  directives    from   the   JCS .      In   January    1982,    a 
WIS    Jcint   Program   Manager    (JPM)     was    appointed  to    control   the 
joint   modernization    activities   of   WWMCCS    ADP   an  i   the    devel- 
opment  of   all  telecommunications    interfaces.      Small 
site-unique    enhancements    will  continue    to    be    processed 
normally.      The    WIS    JPM  receives    direction    from   the    JCS    and 
reports    through    the    JCS    to    the   Secretary   of    Defense. 
[Ref.    8:    p.    44] 

A    System  Progam    Office     (SPO)     was    established    within   the 
Air    Force   Electronic   Systems   Division   to    manage    wis    acquisi- 
tion   and    provide   support    in    such    areas   as    architecture    end 
system   engineering.       The   SPO   also   maintains    Air   Force 
programming    and    budgeting   data    for   the    WIS    modernization 
plan.      [Hef.   8;    p.    44]  T  ae    Director,    DCA   and   the    WIS    JPM 
have    signed    a   Memorandum    of    Agreement    which   specifies    the 
guidelines    for    the    Command    and  Control   Technical    Center 
(CCTC)    support    to   the    WIS  modernization    effort. 

The    fcasic  goal    for  the    WIS    modernization    program    is   to 
provide    the    NCA,    JCS,    and  Unified   and   Specified   commanders 
with    real   time    access   to    status   and    warning    information. 
WIS    objectives    include:      improved   WWMCCS    performance, 
greater    WIN    reliability,    modernization    of    WWMCCS    ADP   harware 
and    software,   and   increased    ADP    security.      Of  the    three 
WWMCCS   ADP    categories   mentioned    previously,    Wis    will 
centralize    its    effort  on    Category    A   --    WWMCCS   standard 
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software.      Cf  the   four  functional   families   of  operational 
requirements,    WIS   will  focus   only  on    two:      Resource    and   Unit 
Monitoring    (ROM)    and   Conventional   Planning   and   Execution 
<CPE)  .      The    Air    Force   will    continue   to    manage  the    WWMCCS   AD? 
systems    in    the    Nuclear  Planning   and    Execution    (NPE)     and 
Tactical    Warning/Attack    Assessment   and   Space   Defense    (TW/AA 
and    SE)    areas.      [Hef.   8:    p.     18] 

E.       SYSTEM    DESIGN 

The    «WMCCS    Information    System    (HIS)     was    designed    as   an 
interactive    network    systam    in   which   a    user   at   any   command  or 
agency   can    communicate  with    a   user/host    at    any   other   command 
cr   agency    also    connected    to    the    network.       The    Defense    Data 
Network    (CDN)    >ill    provide    the   interconnection  among    WWMCCS 
sites.      A    Network  Operations   Center    will    monitor    the   network 
as   a    separate  node    on  the   DDN.       Local   area    networks     (LANs) 
will    exist    for    secure   and  interactive   communications.      The 
advantages   to  LANs    include:       usual  aase    in   configuring 
systems   to   meet    specific   site   requirements,    development   of 
standard    components    for   common   functions,    flexibility    for 
selective    -nodern  izat  ion,    and   the    ability    to   develop    incre- 
mental  security    solutions.      Figure   2.1    graphically   depicts 
the    user    support   scheme    envisioned  by    WIS. 
[Ref.    8:    p.    3] 

The    WIS    system    objectives   include: 

(1)  user-friendly   interface    development 

(2)  data   processing    capabilities    for   all    WWMCCS 
sites 

(3)  reliable    inter- command  communications 

(4)  improved    processing   capabilities    during    battle 
conditions   [Ref.    8:    p.    15] 
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LOCAL  USER. 
WORK  STATIONS 


•  OUTGOING  MESSAGES 

•  QUERY/RESPONSE 

•  TELECONFERENCE 

•  DISPLAYS 

•  DATA  BASE  SUMMARI 


JRS  MESSAGES 
OTHER  MESSAGES 
QUERY/RESPONSE 
•  TELECONFERENCE 
•  DISPLAYS 

DATA  OASE  UPOATES 
FILE  TRANSFERS 


EXTERNAL  INTERFACES 


LOCAL  USER  WORK  STATIONS 

•  COMMANO  CENTER  PERSONNEL 

•  CRISIS  ACTION  TEAMS 

•  OPERATIONS  SUPPORT  PERSONNEL 


Figure    2.1        User  Support   Overview. 
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Projected  WIS  characteristics  to  accomplish  these  goals 
are  divided  into  three  categories:  access,  availability,  and 
modularity. 
access  characteristics: 


(1 
(2 
(3 

<<* 
(5 

fivailabili 

(1 

(2 

Modularity 
(1 
(2 
(3 
(4 


organic    SIS    support    for   major   sites 
remote    access   capability    for    small   sites 
user  access   from   a   single   work   station 
a   multi-level  security  system 
minimum    site   training  requirement 
ty  characteristics: 

secure    and  interactive   network 
operational   for    day-to-day  and   crisis    support 
and    flexitilty  characteristics: 
accomodation    of    a  wide  range   of   sites 
stan3ard    software 

minimum    implementation   disruption 
state-of-the-art   technologies    considered 


[Bef.   8:    p.     16] 

C.       SISTEB    STRUCTURE    GUIDELINES 

The    WIS    JPM    Cffice  has    developed    guidelines    for    WIS 
system   requirements    in  the    areas   of    standardization, 
security,    and  system    characteristics. 

Hardware  standardization    will   not    be    mandatory    because 
of    the    numerous    existing   systems    and   the    competitive 
procurement    possibilities.       Software    development    standardi- 
zation   will    be    achieved   through    the    exclusive   use    of    ADA    as 
the    program    design    language.      Standard,    pr e-determined 
protocols    will    set    the  intercomputer    communications   stan- 
dards.     Routine    and    emergency   maintenance    will    be    monitored 
by   a    single   organization;    maintenance   standards    will   be 
imposed.      To  facilitate  cooperation   among    the  remote   sites, 
data    definition    standards   will    be   implemented.      [Ref.    8:    p. 
31] 
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The   core  of    the    WIS    security    program   lies   in    the    multi- 
level  secure  LANs   with  secure   interfaces   to   all    other   Wis 
components.      Authentication    for    users    will    be  applied   as   a 
security    ccntrol   with   an   audit,   capability   available.       DCD 
security   requirements  require  that   a    multi-level    security 
system    be   achieved    within  the   WIS   modernization    program. 
[Ref.    8:    p.    34] 

The    WIS    modernization   program   will    provide  capabilities 
to   improve   communication    survivability   and   AD?   support    to 
WWMCCS    sites.      Seme    proposed  capabilities   are: 

(1)  distributed   and/or    redundant   processing    with 
rimcte   access 

(2)  graceful    degradation 

(3)  rapid   restart  and   recovery 

(4)  distributed    data    files 

(5)  transportable  systems 

Standards   for   accessibility    include    the   ability    to 
access   all    wis-related  capabilities    from   a    single    worksta- 
tion.     Other  required   system   capabilities   are    flexibility, 
reliability,   maintainability,    and   interoperability. 
[Ref.    8:    p.    35] 

D.        IBPLEBENTATION 

WIS    will  be    implemented    during   four    modernization 
segments    and  utilizir.g  four    major  contracts.      The 
Maintenance    Segment    includes   the   near-term    enhancements   to 
the    baseline   hardware  and   software  to   stabilize    WIS    perfor- 
mance   and    will    be    accomplished   through   the   Integration 
Contract.      Next,    the    Transition    Segment,    linked   to   the 
Common    User    contract,   transfers    the    user    communities    from 
the    existing   WWMCCS    ADP    to    the    WIS   modular    architecture    for 
future   modernization    and   initiates   the   Automated    Message 
Handling   capabilty.       The   Joint   Mission   Segment   concentrates 
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en    th€    common  applications    software    modernization;    the    Join- 
Mission    Hardware   contract   will   provide  -he   standard    hardware 
case    and    supporting    operating   system    by   late    FY85.      The 
final    segment   will    be  the  Service  and  Command   unique   appli- 
cation  software    improvements    which   will    be   the 
responsibility    of   the   Services  and   user   commands.      Figure 
2.2    illustrates    the    HIS    growth   through   the    four    moderniza- 
tion   segments.       [Hef.    8:    p.    3]   The   last    major   contract,    the 
Configuration  Management   contract,    provides   for    independent 
validation   of  the  software    provided    by   the    Integration    and 
Common   User    contractors.      In   addition,    this   contractor    will 
assist   the    WIS    JPM    in  the  overall   configuration    management 
of    WIS.      [ Re f-     13:    p.    9] 

E.       EvALUATICN/COMPABISON    EFFORT 

As    mentioned  earlier,    one   of    the    major    problems    in    the 
WWMCCS   community   is    the   unsatisfactory   performance   of   the 
WWMCCS    Intercomputer    Network    (WIN).      In    September    1981, 
Director,    DCA  organized    an    effort    to    investigate   the 
replacement    of    the    present    WWMCCS    network    system    with    a    mere 
contemporary  system. 

Initially,    the    idea    surfaced    to   take   advantage   of   the 
proven    AUTOEIN    I  technology    and    develop    an    AUTODIN    II.      It 
was    envisioned    that    AUTODIN    II    would    provide    a   common    use- 
data    network   with   a    multi-level    security   system    to    meet 
network    reguirements    through    1985.      In    1976,    the    contract 
was    awarded    to    Western  Union,    Inc.    and    the    Initial 
Operational   Capability    (IOC)    was   set    for   January    1979. 
[Ref .    14:    p.   HH ] 
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Eeginr.ing  in    1979,   the    IOC    date   was    extended    savsril 
times    until   July    1980,    when    the    Assistant    Secretary    of 
Defense    fcr   Command,    Control,   Communications   and 
Intelligence    (ASDC3I)    requested   a  review   of   the    AUTODIM   II 
project    with  some   possible    alternative    proposals.      In   July 
1981,    the   Deputy   Under   Secretary    of    Defense    for    C3I 
(DUSDC3I)    questioned   the   wartime   survivability  of    AUTCDIN 
II.       Ihe    doubt    focused   on   one    of    the    basic    design    criteria 
for    the    system    --    a    small   number    of   switching    nodes.      These 
switching   nodes    would    require    manning    and    would    be   rela- 
tively   expensive.       Immediately    after    this,    the   Air    Force 
Test    Director  issued   a   report  concerning   the    increasing   cost 
of    the   system   and   doubts    about    the  technology   and    future 
systen    performance.      [Ref.     14:    p.    45] 

In    late    198  1    the    Director,    Defense   Communications    Agency 
(DCA)     established   three    design    teams: 

Team   1    --      tasked  with    designing    the    best    possible, 
survivable    A0TODIN    II   system 

Team   2    --  tasked   with    designing   the    best    alternative 
which   would    te  based    en    the    ARPANET   and    WIN    tech- 
nology,   a   Replica   approach 
Team   3    --   a    30-day    evaluation    team. 

The    evaluation    team   was    to    establish   guidance    fcr   the 
two    design   teams  and    develop   evaluation    criteria.      [Ref.    1<*: 
p.    45]    Seme    of    the    evaluation   factors   considered    were 
survivability,    security,    system    design,    and   cost.       The 
ARPANET    replica    proposal,    referred   to   as   the    Replica,    seemed 
better   able   to    withstand   network    element    losses,    proposed  a 
itore    flexible  routing  algorithm,    and    afforded  a    greater 
mobility   capability.      [Ref.     15] 

AUTOEIN    II    now    had  a   six-year   old    design    and,    because  of 
continuous    technology   advances,    the    expected   life    of   a 
computer    system    is    about    eight    years.       In    the   area   of    large 
data    transfers,     AUTODIN    II    was    superior    to    the  Replica 
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design.      The   Replica    design    would   be    using    smaller    packets 
for    message   transfers   throughout    the    network    —    smaller 
packets   necessitate    more   numerous   packets   which   in   turn 
increase    the  overhead   traffic   through    the   system    and    car. 
degrade    system    performance.      If    AUTODIN    II    had   been    avai- 
lable   fcr    inplementation   during    the    evaluation   effort   time 
frame,    the    technology,   schedule,    and    cost    risks    associated 
with    the    Replica    proposal   would    certainly   have   cancelled 
some    of    the    benefits.      However,     having   no    satisfactory 
AUTODIN    II    system   online,    the   benefits   of    the    Replica 
approach    justified   the  risks.      [ Ref .     15] 

In    constant    FY82    dollars,    AUTODIN    II   total   system   cost 
was    estimated  at    $588    million   where  the    Replica    total    system 
cost    was    $429    millicr.      It    was   projected    that   the    AUTO CIS   II 
annual   operating  costs  would  steadily    increase  to    572 
nillicn    until   1995,    where  the   annual    cost    would    level   off 
near    $55    nillion.      The  Replica    system    annual    cost    is 
expected   to    peak   at    $71    million   around    1985   and   steadily 
decrease    to    the    $40    million    range    in    1987.      Figure    2.3    shews 
DDN/Eeplica    annual    ccsts.      [Ref.     15] 

In    February    1982,   the   evaluation    was   completed.       Sased 
en    the    conclusions    the   Director    of   DCA    decided  the    Replica 
apprcach    would    provide  a    better    DOD    data   network. 
Consequently,   the   Deputy    Under   Secretary   cf   Defense    crdere-3 
the    termination    of    the   AUTODIN    II   network    and   the    initiali- 
zation   of   the   Replica    design,    to    be    known    as    the    Defense 
Data    Network    (DDN)  .       [Ref.     14:    p.    45] 

F.       DFFEHSE    DATA    NETSORK 

The    Eefense    Data    Network    (DDN)    will    provide    the    wis 
community   with    the    secure,    reliable,    interactive    network 
necessary   tc   perform    its   functions.      The    DDN   is   designed   as 
a   single,    integrated    packet -switching    data    network.      The 
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Figure   2-3        DDN/Replica    Annual   Costs 


compl€t=d    network    will  have    91    subscriber    systems    with 
approximately  488   hosts  and    1,446   terminals.      There?   will    be 
171    switching  nodes    at  85    sites.       The    DDN    meats    the 
Worldwide   Digital  System   Architecture    (WWDSA)    standards   and 
objectives    by  providing    a  solid    technology    base,    low    risk, 
and    a    cost    effective    system.      This   network    will    satisfy 
current    survivability   requirements  during   a   crisis    and    meet 
COD    intercomputer   telecommunication   requirements    supplied   by 
the   JCS.      [Bef.     16:    p.   2] 

The    major  DDN   design   concepts   are   standardized   compo- 
nents,   distributed    switching    nodes,    and    automatic    fault 
recognition.      Standardized    components   allow   smallsr    develop- 
ment   costs    and    lower    maintenance   and    support    costs.       Also, 


component   modularity    reduces   the    maintenance    impact. 
Distributed   switching  nodes    aid    in   eliminating  chcke    points 
which    increases    the    overall    survivability   of    the    system.      A 
wide    distribution  of   switching   nodes    asually    minimizes    any 
impact   after  a    single   node    failure.       Another    ms.jor   concept, 
the    DEN    automatic   fault   recognition   system,    is   implemented 
through    a   series  of    Monitoring   Centers    (ffCs)    which   are    in 
continuous   cperation    to   monitor    network    performance   and 
identify   trouble  areas. 

The   network    Monitoring    Centers   will    be    key  nodes   on   the 
DDN    network.      There    will    be    a   principal    system   MC,    an   alter- 
nate   MC,    regional  MCs   for  Europe   and    the    Pacific    area,    and  a 
MC    for    each    keyed   community.      Primary    functions    for    the 
monitoring   centers    will   include: 

(1)  monitoring  the    status   of    the   network 

(2)  isolating   network  faults 

(3)  supporting  software    maintenance 

(4)  providing   network   element   information   [Ref.    16: 
p.    5] 

The    Defense    Data    Network   will   provide    four    levels   of 
support    to   the    current   WWMCCS  community; 

Level   1    —   hcst    processor   sites    for   Resource   and 

Unit  Monitoring    (RUM)    and   Conventional    Planning   and 

Execution    (CEE)     support 

Level  2    —    limited    on-site   processor    support    plus 

access    to   remote   host    processors 

Level   3    —    processor   support    through   network   access 

to   remote    processors   in    Hawaii 

Level  4    —    support    through   individual  terminals 

connected   to    remote    hcst   data    processors    £Ref.    8:    p. 

27] 
The    Defense    Data    Network   is    designed    for    continuous 
operation   tc   support    real  time    handling    of    ail    user's 
traffic.      The  availability    goal    is   greater    than    99%    for   any 
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pair    cf    users.       [Ref„    17:    p.    5]    The   three    major    DDN    £js*--<?.® 
elements   are  switching  nodes,    IPLIs,    and   Mini-TACs. 

The    switching   r.cde   used    for    the   DDN    is   a    Eolt    Beranek 
and    Newman    (EBN)    C/30  switch,    a    microprogrammed    minicomputer 
designed    for   unattended    operations   which   eliminates   the   need 
for    DEN   dedicated  personnel    at    each   switching   node.       The 
throughput   capability   of   each  C/30   node    is    300  packets    per 
second   in   tandem  processing    --    300   packets    in,    300    packets 
switched,    and   300   packets  out    simultaneously,    for    a    total   of 
900    packets    being   handled.       The    long    term    reliability   goal 
is    5000    hours  or   greater    for    Mean   Time   Between   Failures 
(MTBF).      The  developient    risks   are   low   since    the    C/30    switch 
and    its    software  are    functioning    elements    on    such    networks 
as    the    ARPANET;     WIN;    Community   On-Line    Intelligence    Network 
(COINS);    Intelligence    Data    Handling   System,    Communications 
(IDHSC)  ;    and  the   European  Movement  Infcrmafion   Network 
(MINE!).      Technology    risks    are    considered    low   since    only 
minor   modifications    are  neccessary.      [Eef.    16:   p.    33] 

The    Internet   Private   Line   Interface    (IPLI)    is    based   on 
the    Private    Line   Interface     (PLI)     which    has    been    used   on   the 
ARPANET    and    other   networks    for    more   tha.n    five   years.      The 
PLI/IPLI    technology    allows    the    simplest    of    end-to-end 
encryption   available.      An  ILPI    will   reside    between    a   host 
and    switching   node    or   Mini-Terminal    Access   Controller 
(mini-TAC)    and    switching    node,    depending   on    site    configura- 
tion.     The    IPLI    is    currently    under   development    with    an 
initial    delivery   date  of   July    1983.       It    will    support    the 
standard    EOD  protocol,   Internet   Protocol    (I?) ,   and    widesp- 
read   deployment    is    expected    because    of   reduced   cost,    size, 
and    power   and   weight    reguirements   from    the    PLI   currently 
being   used.      The   IPLI   hardware   consists    of    a    KG-84    crypto- 
graphic   device    and    two  Motorola    MC68000- based   packet 
processors.      A    minimum  of  fifty    packets    per   second    is    set    as 
a   throughput  goal   and  the   MTBF   goal    is    at    least    5000    hours. 
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The    Mean   Time  To   Repair    (MTTR)    is   expected   to   be    approxi- 
mately   thirty   minutes   with    an  availability   of    99.93.      The 
IPLI    requires  no   additional    personnel   and  the   maintenance 
and    mcnitcrirg    systems  may    be  operated   from   a   remote    sits. 
The    devalcpment    risk    involved  is   considsred  low    due   to   the 
traditional   architecture  used.      [Eef.    14:    p.    39] 

A   Mini- Terminal    access    Controller    (mini-TAC)     is   a 
terminal   access    device  which   allows   a   cluster   of    up   to 
sixteen   terminals   sinuixareous   access   to   the    network.      The 
hardware    of    a  mini-TAC  is   a    MC68000    microprocessor    with 
memory   and    multiple    network    interface    ports.      The   mini-TAC 
software   is   based  on    the   software   developed   for    use    en   the 
ARPANET    and   allows    terminal    users  to    establish  connections 
between    their  terminals   and    an   arbitrary   host   on    the 
network.      The   DOD  standard    IP  and   Transmission  Control 
Protocol     (TCP)     are    used.      The   iiTBF  goal    is    greater    than    5000 
hours   and   the   board- swap ping   capability    simplifies    mainte- 
nance.     Since   the    mir.i-TAC    is   also   designed    fcr    unattended 
operations,    no    dedicated    personnel  are   required.       Control 
menitcring   and   hardware/software    fault    isolation   can   be 
accomplished  remotely   by    the    MCs.      Mini-TAC  availability    is 
expected   during    FY84*     [ Ref  -    16:    p.    42] 

Cne   cf   the    major    comparison    factors    for   the    AUTOCIN 
II/DDN    evaluation   was    survivability.       The    small    number    cf 
nodes    proposed    fcr    the   AUTODIN    II    system    left    major    doutt    as 
to    its    survivability.      DDN?s   survivability    features    include: 

(1)  redundancy  --   the    final    system    will    comprise    171 
switching   nodes,    9    fixed    monitoring   centers,    and    5 
mobile    r econstitution   nodes    with   MC   capability 

(2)  disseminated  switching  nodes  --  geographically 
dispersed  sites  afford  the  higher  priority  users  a 
greater    chance  of   reconstitution 

(3)  a   dynamically   adaptive  routing    algorithm    which 
automatically   reroutes    traffic   around   heavily   cong- 
ested or    damaged    links    and   nodes 
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(4)  graceful    degradation    because   of  the   network's 
response    to    damaged    nodes 

(5)  four   levels   of    precedence/preemption    processing 

(6)  hardening   and  HEMP   protection   including   electro- 
magnetic shielding,    line    isolation,    and    power   surge 
protection 

(7)  reconstitution    —   the    five    mobile   reconstitut ion 
nodes  will    be   positioned   in    areas    less   likely   tc   be 
targeted  and    all   users    will    have    a    detailed    alterna- 
tive routing    plan 

(S)  preplanned  rehoming  --  all  users  will  have  a 
priority  listing  of  switching  nodes  for  rehomirg 
[Ref.    16:    p.     125] 

DEN    security    will    be   accomplished    through   link    encryp- 
tion,   end-tc-end   encryption,    and    physical    and   procedural 
security    measures.       The   KG-84   cryptographic   devices    will 
provide    the    necessary   link   encryption.      The   Internet    Private 
line    Interface     (IPLI)    devices   between   the    host   and    switching 
node    cr    mini-TAC   and    switching    node    will    provide   the 
end-tc-end   encryption.      The    IPLI    will    also    separate    subscri- 
fcers    operating    at    different    system   security   levels.      For 
physical    security   measures,    ail    switching    nodes    will    be 
TEMPEST    enclosed    and    located   in    secure    military    facilities. 
Only    System   Monitoring  Center    (SMC)     personnel   will    be   able 
to   retrieve   traffic    statistics.       All    personnel   at    regional 
and    system    !*Cs    and    personnel   with    access    to   switching    redes 
will    held   a    SECRET    clearance.      In   addition,    personnel    with 
access   to   a    MC    for    a    secure    subnetwork    must    also    be    cleared 
to   the    highest    security   level   of    the    subnetwork    subscribers. 
[Ref.    16:    p.    12] 

The  ECN  program  office  is  within  the  DCA  organization 
and  consequently  comes  under  DCA's  staffing  and  policies. 
The  National  Security  Agency  (NSA)  has  the  responsibility 
for   certifying    and    accrediting  the   IPLI    devices    and 
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analyzing  the  network  system   design    for    use   with    classified 
traffic.      DDN   subscribers  will   be   responsible   for   acquiring 
the   necessary  hardware  and    software    for    DDN   operation   and 
support.      [Ref.     14:    p.    258] 

Another    major   factor   considered   during   the  evaluation 
phase    was   cost.      According    to   the   evaluation    team,    the    "DDN 
I   system   can  provide    COD  with   a   survivable,    common-user 
systea    at   a    cost   less  than    being    paid    for   the    dedicated 
systems...".      [ Ref .     16:    p.     15]   Using    FY32    dollars,    the    91 
dedicated   systems   listed    in    the    user    requirement;    data    bass 
cost    ever   $35.2    million    for    annual  operation.      The   annual 
cost    for   th=  new  DDN    system    includes: 

System   Management  3,3  54    K         (10.335) 

Trunk/Access  Lines  24,694    K         (    7.6?) 

Operations    and    Management  4,428    K         (13. 6%) 

Total  $32,476    K        Annually 

When    development   and   acquisition   costs   are   included,    DDN 
annual   operating   costs  average    $35,549    million  over    a    ten 
year    period.     [Hef,    16:    p.    255] 

Tbe  Defense  Data  Network  system  design  builds  on  three 
operational  networks  which  use  the  B3N  C/30  switching  node 
and    accompanying  software: 

(1)  ARPANET    —   with    90    nodes    at    75   locations 

(2)  WIN    —    with    26    nodes    at    16    locations 

(3)  MINET   —    with    European   locations   [Ref-    17:    p.    2] 
The    DDN    will   employ    a   four   stage    implementation    approach 

which   should   lead   to    a  graceful   evolution    capitalizing   on 
existing    networks   and   interfaces    with    minimum    risk    for    new 
technologies.      The    ARPANET    will    supplement    DDN's   test    and 
development    facilities  but    will    remain   as    a   scaled-down 
research    network.      It   will    later   serve   as   an   operational 
testbed   for   future    DDN  software   releases.      [Ref.    16:    p.    24] 
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The   four  transition   stages    for   DDN    I   are: 
Stage    1    —    Service  will    be    provided    to    subscribers    that 
can    be   handled    with    minimum    development.       The   WWMCCS    Netwcrk 
C/30    switch    upgrade    will  be    accomplished   during    this    stage. 
Communities   of    interest   and    networks    with   differing    security 
leve.'ls   will    be    physically  separated   into   three   distinct 
networks: 

(1)  Strategic   Air   Command  Digital    Network    (SACDIN) 

—  at  a    Top    Secret     (TS)     system-high   security    level 

(2)  Military    Network    (MILNET)     --    for    unclassified 
subscribers    tc  include   military    ARPANET    users 

<3)    Command    and   Control    Intelligence     (C2I)     Network 

—  with    a   TS    system-high    security    level    netwcrk    with 
twc    subnetwork  communities: 

the  C2   Comnunity    basically    for    WIN    subscribers    and 
the   Intelligence    Community    primarily   for    IDHS 
II/Department    of    Defense   Intelligence    Information 
Systems    (DCDIIS)     users. 
Stage    1    is    expected    tc  be  completed    by    end   of    FY33. 

Stage    2    —    As   additional  IPLIs  become    available    during 
198H,    more   subscribers  will    be    added    to    the   network.      The 
mini-IACs    will    be    implemented   in    Stage    2,    also.       Completion 
is   expected    by    the    end  of   FY84. 

Stage    3   —    During   Stage    3r    the   three    separate    networks 
originated   during  Stage    1   will    be   integrated   to   become    the 
DDN    I,    supporting   multiple    levels  of    security.      During   this 
stage,    additional   classified   subscribers    will  be    incorpo- 
rated   intc    the    network.      Stage    3    will    be    completed    by   the 
end    cf    FY85. 

Stage   4   —    As  hcst  interfaces  are   developed,    ail 
remaining   DDN  subscribers   will   be   included   in   the    network. 
The    final   DDN   I    netwcrk    will  consist    of    171    nodes   supporting 
91    systems,    and    the    CEN   system    design    allows    for    a    moderate 
increase    in   traffic    from    each   netwcrk   user.      [Ref.    16:    p. 
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189]    Figure    2.4    shows   the  transition    plan    for   the    DON    I. 
[fief.    16:    p.    190] 

G.        WIS/EEN    CONNECTION 

Currently,    the    Defense    Communications   Agency    provides 
WWMCCS    software    suppcrt   through    the    Command   and    Control 
Technical   Center    (CCTC) .      Although  the   wis    modernization 
plan    is    net    a   part    of   DCA,    the    WIS   JPM   and    the   Director   of 
DCA    have    entered   a    Memorandum  of    Agreement    which    insures 
CCTC    support  during    the   WIS    modernization   effort.      Hcwever, 
since    plans   call   for    the   Defense    Data    Network    (DDN)    to    be 
integrated   into    the    ECS,    the   DDN    program   office    falls    under 
the    DCA    organization .      The    DDN    will    provide    a    common    user 
network,    capable  of    incorporating   the   majority   cf    the   C3 
networks    available    tcday   and    providing    a    standard,    secure 
and    shared-resource    capability. 

The    DEN    will   not    be   restricted  to   support   cf   the    WWMCCS 
community.      As    can    be   seen    frcm    Figure    2.4,    networks    such   as 
the    SAC    Digital    Network    (SACDIN)     and    the    ARPANET    will 
utilize    the   Defense    Data    Network    for    intercommunications 
among    member  sites.       With   these    various    user    communities 
riding    en   one   network   system,   a    multi-level   security   system 
is   imperative,    although   technology   hinders    the   development 
cf   such    a    system.      The   management   of    the    DDN    network,    a 
network    where  users    range   from   unclassified   military   users 
en   the    ARPANET    tc   high  classification    users   of   the    JDS    on 
the    WIN,    has  not    been   sufficiently   addressed    and    will   become 
the    scurce   cf  major    problems. 

As    DDN    comes   intc   being,    new    WWMCCS    standard    software 
will    be    implemented    under  the  WIS    modernization    plan   and 
existing    site-unique    software    will  be    modified  to    reflect 
the    updated    system.       These    software   changes    and    future    hard- 
ware   acquisitions    will  affect  every   system    used    within    the 
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WWMCCS    community .      The   WIS    modernization   impact    will    be    felt 
by   all    users  supported  by  the  Joint    Deployment   System    (JDS), 
cne    of    the    most    widely  used    WWMCCS  systems   and   the    total 
management   system   coordinating   the  links   between    deliberate 
planning,   time-sensitive    planning,    and   deployment    of    forces. 
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III.     JOINT    DEPLOYMENT    SYSTEM 

A.       EACKC-BOUND 

In    October    1978,    the    JCS   conducted    a    command    post    exer- 
cise,   NIFTY    NUGGET,    to  test    full    mobilization    and    deployment 
capabilities  for   U.S.    forces.      NIFTY    NUGGET    exposed    defi- 
ciencies   in   both   the    military  deployment    planning    and 
execution   process   as    well   as   the   supporting  Management 
Information    System     (EIS) .      The   systems   most    widely    utilized 
during    NIFTY  NUGGET    included  the   Joint   Operational   Planning 
Systeir     (JCPS),    Unit    Status    and   Identification   Report 
(UNITEEP)    System,    and   command    unique    systems    such    as   the 
Deployment    Management   System    (DEPMAS)    used    by   the    U.S. 
Readiness   Ccmmand    (USREDCOM) .      JOPS    supported   planning    but 
supplied   no    support    fcr   the    execution    phase.      The   UNITfiEP 
system    was   net    responsive  tc   time-sensitive   decisions. 
CEPHAS    was    not    available    to    the    joint    deployment    community, 
the    system    dealt    with   Army    and   Air   Force    forces    only.       The 
need    fcr    a    centralized  deployment    and    decision   support 
system    fcr    planning    and   execution   was    evident.       In    March 
1979,    the   Jcint    Deployment    Agency     (JDA)     was    established   tc 
support    the   JCS    and    supporting   commanders    as    the    nucleus    of 
depioymsnt    and    associated  activities.      [  Ref .    10:    p.    3] 

The    Jcint   Deployment    System     (JDS),    resident    at    the    Jcint 
Deployment    Agency,    was  created    to   support    the   JDA    mission. 
The    JCS    includes    personnel,     procedures,    directives,    communi- 
cations   systems,    and   electronic    data    processing    systems 
which    support   peacetime    planning    and    time   sensitive    planning 
and    procedures.      The    JDS    concept    is   the    development    of    a 
single    support    system   for  all   stages    of    deployment    manage- 
ment   with    particular    focus    on   planning,    deployment 
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execution,    and    crisis   monitoring.      After   the   JCS    exercise 
order    is    delivered,    the   JDS    allows  the   monitoring   of    move- 
ment   of    forces,    materiel,    and  non-unit   related  personnel. 
The    Master   Force   List    (MFL)     file,    schedule    file,    scheduling 
requirements  and   UNITREP   data   are   generated   from    the   deploy- 
ment   data   base    and    distributed   to   users.      [Ref.    10:    p.    18] 
Through    the   JDS,    the   Joint    Chiefs   can    achieve   direct   imple- 
mentation  of  their    deployment   decisions    during   peacetime, 
command    post  exercises,    crises,    and    war.      [Ref.    18:    p~    1] 

E.       JES/WIN    LINK 

The    mission    of    the  JDA    obviously    depends   on    interccnr.ee- 
tivity   among  the    joint  deployment    community.      The    WWMCCS 
Intercomputer  Network    (WIN)     is    used   to   organize    these 
geographically    separated    host   computers    into    a   single 
netwerk    ard   becomes    the   backbone    of    the    JDS   communications 
system,    essential   in    the   planning   and   execution    of   deploy- 
ment   decisions.       The    deployment   data    oase    depends    on    WIU    fo: 
accurate   information    exchange   between   user    sites   and   the 
JDA.      [Ref.    19:    p.    1]   Figure    3.1    illustrates   the    WIN    rela- 
tionships   within   the    joint    deployment    community.      [Ref.    20: 
p.    12] 

Transaction    throughput    is   site  dependent   but    a    JEA   site 
will    usually  average    1200  transactions   per    hour.      Dser 
response    tine   is   dependent    en   the   number   of   users    simultane- 
ously   accessing    WIN.      For   example,    with    an    average   of    ten 
simultaneous  users,     SIN    response    time    averages  two   to    five 
seconds.      Ten  is    considered    a  small    number    of   users    and    one- 
ever    ten,    significant   performance   degradation   is    experi- 
enced.     [Ref.    18:    p.    13]  The   WIN    software   available    for 
transactions  include    TELNET,    the    Telecommunications    Network 
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Program  used  for  message  exchange  ar.d  direct.  access  to 
resources  of  remcte  hosts,  the  File  Transfer  Service  (FTS) 
used  mainly  for  large  bulk  transfers  between  sites  (i.e., 
the  TPFDE  file  and  TPFDD  file  changes) ,  and  the 
Teleconference  (TLCF)  capability  which  simultaneously  links 
any  number  cf  WIN  nodes  into  a  textual  exchange  conference. 
AUTODIN  is  the  general  message  exchange  system  which  may 
also  te  used  for  guery/response  activities  and  NACE  trans- 
fers data  between  the  JDS  and  AUTODIN,  automatically 
formatting    the    messages   generated   by    JDS.      [Ref.     10:    p.    18] 

C.       AEP    GCALS    ANE    CAPABILITIES 

The    Joint   Deployment    System    ADP    criteria    goals    include 
an   availability    cf    2U   hours    a   day,    7    lays    a    week,    except    fcr 
scheduled    maintenance   and  unexpected    outages.      The   operatic?, 
goal    is    95^    for    routine    processing  and    99%    for   crisis    and 
exercise    operations.      The  deployment    data    base   is    resident 
at   JDA    with    the    irajor   backup   at    R2DC0M.       The    JDA    and    SEECOH 
computer   systems    are    comprised   of    four    processors    organized 
in    dual    ccnf igur at icr.   with    shared   disk    drives,    colccat~d    in 
the    same    facility.       The   JDS    reliability    goal    for    MTBF    :'.s    36 
hours    with    l^TTR    of    10    minutes.       When    fully    developed,-    JDS 
will    he    a   transaction-oriented   communications   system   capable 
of    real-time  processing    on    a    distributed    data   base    within 
the    WIN    environment.      [Ref.     10:    p.   32] 

The    JDS    computer    system    availability   not    only    depends    on 
the    hcst    computer   up/dcwn   ratio;    other    factors   include   the 
supporting    WWMCCS  system   software  such   as   the   Time-Sharing 
Systei    (TSS)    and  the    General   Comprehensive    Operating    System 
(GCOS)  ,    the    JDS    software    which    includes    the   Remcte   User's 
Package     (HUP),    and    WIN  availability.       All    cf    these    ccmrc- 
nents    must    be  available   for    a    remote    user    to    access    the 
deployment    data    base.      JDS    will    allow    interfaces    with 
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appropriate    service    and   com mand- unique   data   systems    for 
accurate    information    flow  among    the    joint   deployment 
community. 

Th€   JDS    is    divided   into    5    procedural   subsystems: 

(1)  plan   genera-ion    —    expansion   of  the    data    base 
fcr    inclusion  of   new  data 

(2)  plan   maintenance   —    modification    of   the    data 
case  to    reflect   changing   resources    or   constraints 

(3)  execution   preparation   —    adjustments    to    plan 
data  to    account    for    real    world   dates   and   require- 
ments 

(4)  scheduling  --   coordination    and    distribution    of 
transportation  schedules    developed    in   conjunction 
with  the   Transports  ting    Operating    Agencies    (TCAs) , 
i.e.,    Military   Airlift   Command    (MAC),    Military 
Traffic    Management    Command    (MTMC),    and   Military 
Sealift    Command    (MSC) 

(5)  movement    monitoring    —   reporting    of    the    status 
of   the    deployment,    departures,    and    arrivals 

[Bef.    10:    p.    20] 
The    Joint   Deployment    System    offers   the    joint    deployment 
ccmnunity    five    processing   alternatives: 

(1)  Time   Sharing    System     (T3S)    --    simultaneous   access 
of    the    computer   system    by   more    than   one    user 

(2)  batch    updating    —    primary    system    for    JDS    data 
base  control 

(2)     transaction    processing   --    data    base    updating 
through    one    of  twenty-three    Transaction    Service 
Modules     (TSMs)    which    maintain    a   near    real-time 
information    flow    between    WIN    sites 

(U)     stand-alone    programs    —    software    sent    over    the 
WIN    network    to   update  the   JDS    data    base 

(5)     Remote    User's    Package    (RUP)     --    provides    the 
capability    tc   send    and    receive    transactions    from 
ether   WIN    sitas   [Ref.    21:    p.     34] 
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Users    may  access    lccal    or  remote    deployment    data    bases 
using    any   one  of   four   methods.      Twenty-two    on-line   queries 
are    available   on   the    time   sharing    system.      The   Management 
Data    Query    System    (MECS)     for    retrievals    allows  the    user   tc 
originate   a    batch   process   for   information   retrieval    from   the 
Master    Force  List    (MfL)    file   and   schedule    files.      The    MFL 
file    also   allows   users  without    the   HUP  capability   to 
initiata   information    queries.      Users    can   also   utilize   the 
automatic   scheduling    messages   package   to    automatically 
receive    movement   data    for   the   next  twenty-four  hours   through 
the    NJfCC    Automated    Control    Executive    (NACE)  .      [fief.    21:    p. 
65] 

D.       DEVEICPMEMT 

The   Jcint  Deployment   System    is  being   developed    in    five 
stages.      The   Baseline  Stage    has    been    completed  and   JDS    now 
provides    service   to    the    jcint  deployment    community.      The 
Initial    Cperational    Capability     (IOC)     for    the    second    stage, 
which    includes    limited  on-line    update    and    query    features, 
distributed    processirg   support    via   tne    Reaicts   User's    Package 
(RUP)  ,    and    data    base    backup    at    R2DC0M,    was    achieved    December 
1982.      The    third   stage   incorporates    long-term    requirements 
definition    and    validation.       These    additional   requirements 
will    support   the   Crisis    Action   System     (CAS)    and    will    empha- 
size   such   things   as    nulti-plan    support   and    no-plan    support. 
The    fourth   stage   is    Bull   Operational    Capability    (FOC)    and 
the    ICC    is    presently    December    1985.       Since   JDS   is    the    center 
cf   the   Conventional    Elanning  and   Execution    (CPE)     functional 
family   of   the  WWMCCS    ADP    program,    the    fifth   stage,    Post-FOC, 
will    detail    the    JDS    integration    into    the    WIS    modernization 
program.      [Bef.     10:    p.   78] 
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Tfce   JDS   data   base   presently   contains    108   record   types 
chained    in    logical    record  relationships    in    the   Honeywell 
Integrated   Data    Store    (IDS)     structure.      The   data    includes 
information   en    forces,   nonunit   personnel   and   cargo,    move- 
ment,   and   transportation.      The  JDS   is    a    conglomeration    cf 
375    application    programs   and    subprograms    which  maintain    and 
manipulate   the    deployment    data    base.       The    majority    cf    the 
JDS    software   works    or.   menu- selection    and    pre-defined    display 
screens.      Although   the  entire  data  base   is   resident   at    the 
JDA,    various  deployment    community  members    will   maintain 
separate    data  bases    to  satisfy    unique    command   requirements 
and    command   and    control    functions.      Each    of   these    sites    will 
also    maintain   a    Data    Ease  Management    System    (DBMS)     and    local 
access    to    the   main    data    base.      These    distributed    data    cases 
will    re    subsets    of    the  master    data   bass    and   will    be    main- 
tained  concurrently    with    the   master    by  near-simultaneous 
(within   five  minutes)    distribution  of   data   transactions. 
This    distribution   will  significantly    reduce    WIN    activity   and 
network    performance    degradation    associated    with    large   data 
transfers.      The    distributed    data    bases   will   also    enhance   JDS 
survivability   by   providing    multiple    backup    locations    for    JDA 
functions.      [Ref.    10:   p.    25] 

E.       F0HCTIONS 

One    cf    the    major    JDS    functions  is   to    provide    a    bridge 
between    deliberate    planning    and   time    sensitive    planning   and 
execution.      The    two    systems    utilized    during  these    procedures 
are    the    Joint   Operational  Planning  System    (JO?S)     and    the 
Unit    Status    and    Identification    Report    (UNITRE?)     System. 
JOPS    establishes    procedures    for    planning    and   executing 
deployments    during    peacetime    and    crisis    situations    as 
directed    by   JC3;    the    UNITRE?    System   contains    the    location 
and    identification    of   actual  military    units   needed    during 
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the    planning  and   execution    phases    of    deployment, 
supplies    the   necessary  link    between    these    two   systems    by 
maintaining   an    up-to-date  deployment    data   base.      [Hef.     10: 
p.    9  ]   Figure   3.2   graphically   illustrates   the   JDS    connection 
between    deliberate    planning    ard    time -sensitive   planning   and 
execution.      [Ref.    10:   p.    10] 

During   the    deliberate  planning  phase,    Time-Phased   Force 
Deployment    Data     (TPFDD)     files  are   developed    for    a    specific 
Operation    Plan     (CPLAN)    using  JOPS    and    UNITREP.      The    initial 
data    is    collected   frcm  supported    commanders   and    service 
requirements.      The    JDA  holds  a    two-phase    conference    for 
refinement   of  the   data  and    then    the    TPFDD    is    incorporated 
into    the   JDS  data    base   for    that    specific    OPLAN.      This    method 
provides   the  primary   source    of   input    into    the  JDS.      Seme 
problems   with   these    procedures  are   the   time-consuming 
conferences   and    reviews   and    the    manual   manipulation    of   the 
data.      [fief.    10:    p.     12] 
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F.       REHOTf    USER'S    PACKAGE 

Since   the   majority  of  JDS   users   are    remote   and   the    File 
Transfer   Service    (FTS)    on  WIN   has   proven   to   be   slow   ard 
unreliable,    the    Joint   Deployment    Agency   developed    the    Remote 
Oser's   Package     (HUP)    to   offset   some   of   these    problems.      The 
RUP    is    installed  at    selected   WIN    sites   to    alleviate    seme   of 
the    network    overloading   caused   by   large    data   transfers. 
When    utilizing    the    Remote  User's    Package,    no    direct   connec- 
tion   tc    the    JDA    host    via    WIN   TELNET    is    required    to    access 
the    data    base.       [Ref.    21:    p.    26]    Since   the   RU?    permits    users 
to    input,    update    and    query  transactions    via    their    own 
Time-Sharing  system     (TSS)    and  the   data   base   is  then   accessed 
through    WIN,   users    experience  a    significant    degradation   of 
own    TSS    response  time.      The    JDS    Remote   User's   Package 
includes    an    Interface   Processor    (JOSI?) ,    an    Update    Processor 
(JDSUP)  ,    a   time-sharing    package,     and    a    batch   update 
capatility.      [Ref.     1S:   p.    7] 

The   JCSIP   provides  the    necessary    communications    protocol 
for    transaction    processing    between   two    WIN    sites.      The 
sending    site  JDS  I?    breaks   bulk    files    into    individual   tran- 
sactions,   then    the    receiving    site    JD5I?   accepts    e=;ch 
transaction   and    passes  it   to   the   JDS    if    a    WIN    connection    is 
available   or   holds    the  transaction   until   a    connection   is 
made.       An    acknowledgement   is   necessary    from   the    receiver 
tefore    the    next    transaction     (packet)     is    sent.      The    Remote 
User's    Package    essentially    transforms   the   WWMCCS 
Intercomputer  Network   into    a    transaction    processing   system, 
as    was    the    original    design    goal    for    WIN.       The    capabiitiy    now 
exists    for   transaction  update   processing    between  two    WIN 
sites    in    near- reel    tine    without    dependence    on    a    WIN 
connection    to  the  JDS.      [Ref.    19:    p.    9] 
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The   JESIP  of  the   receiving    site    forwards   the   transac- 
tions  to    the  JDS   Update   Processor    (JDSUP)     for   individual 
inclusion    into    the    data    has?.      The   J  DSD?    is    capable    cf 
receiving   input    transactions   from   the    time- sharing   cr    batch 
systen,    WIN    via    the    JDSIP  and   PTS   capability,    and    AUTODIN 
via    the    NACE  processors.      The  Update    Processor   provides 
dynamic    recovery   check   points  during    processing    without   task 
interruption.      If  necessary,    transaction    processing   recovery 
is   achieved   after  a    communications  interruption    using   these 
checkpoints,   thereby    no    longer    requiring    -as    complete 
reinitialization   cf    the    task.      [Ref.     19:    p„    9] 

Although  JDA-generated    software   has   greatly    improved   JDS 
performance,   particularly   in   the    WIN    arena,    additional 
improvements  are   necessary.       JDS    should    be    supported    by 
software    which    requires   a   minimum   amount    of   training    and 
skills    due    to  the   computer    experience    of    :ncst    users;    for 
instance,   JCS  action   officers.      Users   have    recommended   the 
information    displays    be   modified   to    remove    the    time-frame 
distinction    cf    'deliberate'    or    'crisis'    planning.       Although 
the    data    is    now    maintained    quarterly    by    the   Command    and 
Control   Technical  Center    (CCTC)  ,    part   of    DCA,    the    JDS 
deployment    data    tase    should    move   towards    real-time    mainte- 
nance  tc   constantly    provide    a   current    deployment    situation 
data    tase    resident    at   JDA.      [Ref.    10:    p.     13] 

Additional   areas    for    general    system    improvement    include: 

(1)  revising    man-machine    interfaces    for    simplifica- 
tion 

(2)  aggregating    information    for    senior    level 
managers   on    general    JDS    capabilities 

(3)  insuring    more   accurate  and  timely   data    collec- 
tion 

(4)  developing  standard    data    definitions 

(5)  enhancing   the  recovery  and   backup   facilities 
[Bef.    10:   p.    19] 
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!▼•   gyaccs/jps  performance 


As   previously   discussed,    the    information    flow    between 
the    NCA    and    military    forces    depends    upon   a    reliable,    sacure, 
and    survivable    intercomputer   network.      The    WWMCCS 
Intercomputer  Network    (WIN)     was   designed   to   provide    exchange 
of    information    through  computer-to-computer   and   remote 
terminal-to-computer    processing   using   distributed   data    base 
concepts    and  workload   sharing   techniques.      [Ref.    5:    p.    42] 
WWMCCS    svclved    through  the    early    years   as    services    developed 
hardware    and  software   to   meet    unique    requirements.       Eased   on 
the    evolutionary    approach  to   systems    development,    HWMCCS 
should    evolve   through   requirements  specifications    as   opposed 
to    the   traditional    system  acquisition    approach.       This   theory 
is    supported  by    a   lack  of   specific  C3   system    criteria; 
poorly    understood  C3    systems  concepts;    language    barriers 
between    the    policy    makers,    planner.-;,     and    commanders;    and   the 
nebulcus    framework    for  C3   systems   evaluation.      [Ref.    5:    p. 
16]    There   are  numerous  systems    other    than   C3    systems    which 
suffer    from    one    cr    mcrs   of    the    problems    mentioned.      For 
instance,    any   highly    specialized    system    will    likely    experi- 
ence   barriers   among    technologists   and   users. 

As    prcven   with   the  early   WWMCCS,    allowing   users   to 
develop    small,    unique  systems   independently,    precludes    the 
integration    of    these    systems   into  a    responsive,    larger 
system.       Cbviously,    interoperability    was   net   the    primary 
concern    for    these   individual    funding    efforts.      Twenty    years 
later,    WWMCCS  remains   somewhat    fragmented   due   to    the    absence 
cf    a    centralized,    long-range   plan    for    the    management   and 
tudget   ccntrcl    of   WWMCCS   and   the    Defense    programs    affecting 
WWMCCS.       With  the   WWMCCS    Information    System    (WIS) ,    a    Joint 
Program    Manager     (JPM)    Office    was    established    to    provide 
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centralized  management  for  all  aspects  of  the  wwmccs  moder- 
nization pre gram. 

A.   SCFTHABE 

The    cemputer   operating    system    utilized    with    the 
Honeywell   equipment    is   "he    General  Comprehensive   Operating 
System    (GCOS)    designed  by  Honeywell.       Honeywell    also    distri- 
butes  this    operating    system    to    civilian    customers    but    the 
Command    and   Control    Technical  Center    must   extensively   modify 
each    GCOS   release    for  security    additions   and    unique    WWMCCS 
Software    so    the    GCOS    used   within   the    WWMCCS   community    is 
consistently  several    years    behind   the    current   civilian 
version.      GCOS    was    developed    to    support    a    single-site    and 
batch-oriented    user    community   and   has    proven    very    successful 
in    such    situations.       Present    day   C3    system    requirements 
however,    demand    an    online   interactive    processing    capability. 
While    modifications    to  the    Honeywell    hardware   and    software 
have    improved   performance,    the    basic    circuitry  is    designed 
for    batch   processing    ana   optimal    performance    will    net   be 
achieved    in   an    online   interactive   environment. 

With    any  large    data    base    system,    a   Data   3ase    Management 
System    (OEMS)    will    be   developed    to  allow   easy   retrieval    and 
updating   of    the    data    base.    Generally,    these   management 
systems    are    user-friendly   and    require    minimal   technical 
expertise    for   successful    use.      The   DBMS    used    with    WWMCCS    is 
the    WWilCCS    Cat  a    Management    System    (WWDMS).       Since    WWDMS 
resides    on    -.he    Honeywell    equipment,    it    relies   on    the   GCOS 
operating   system;    therefore    WWDMS    was    designed   around    a 
batch-oriented    architecture.      WWDMS    uses   GCOS   to    access 
files    for   retrievals   and    updates.      Because   of   the    ineffi- 
ciencies  of    the    military    version    of    GCOS    in   transferring 
data    in    and    cut    of    primary    memory,    the    performance    of   WWDMS 
is   adversely  affected.      [Ref,    5:    p.    25] 
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Reports   on    the   user- friendly   aspect   of   wwdms    have    net 
teen    favorable-      For    the    most   part,    the    WWDMS    language    is 
oriented   towards   the   more  technical    personnel   and   is  consid- 
ered   tec    detailed    for   the  average    WWMCCS    user    with    minimum 
computer    training.       Consequently,    users    are   not    likely    to 
pursue   the    management   system  capabilities   beyond    standard 
procedures    and    WWDMS1    full    facilities    remained   unused.      Fcr 
the    community  to  exploit    the   systems    and   capabilities   avai- 
lable  in    MWMCC3,    a    u;;er- friendly    and    responsive    DBMS    is    a 
necessity.      Since   the   concepts   of   a    distributed    databse 
management   system  are   new,    a   reliable   query   language   could 
suffice   during    the    development    interim.      It   should   require 
minimum    computer   experience    and    a    minimum    amount    of    special 
training. 

The   need   for   a    Miiti-Le vel   Security    system   will   not    be 
satisfied    utilizing    the  the    current    WWMCCS    Honeywell    equip- 
ment   since   this    design  incorporates   only   two    machine   states, 
or   rings.      The    rtaster  state    accomplishes   the    kernel    func- 
tions   cf   the  operating  system,    password    validation    ana    data 
requests,    as   well   as    the    functions   for    scheduling    and   allo- 
cation   cf   resources.      The   second    state   is   for   user 
applications  programs,    referred   to   as    the    Slave    state. 
[Hef.    5:    p„    29] 

Since    the   security  protection    procedures,    all    system 
software,    and  the   resource    allocation   procedures   reside   in 
the    same    ring,    access   to    the   specified   ring   area    is    common 
to    all    users  with   access    to    any   one    section    of  that    ring. 
The    current    theory    is   that,    under   this   scheme,    any    geed 
systems    programmer    should   be    able   to    penetrate  the    kernel 
section    and    gain   access   to    all    passwords   and    security 
checking    procedures. 

Security  alternatives  to   a    ALS   system    are    dedicated 
computers,    scheduled   operations,    and   system-high   security 
operations.      With   dedicated    computers,    a    separate    computer 
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is    required    for    each    security   level    and   individual    data 
bases   are   required    fcr  each    application    requirement    within 
the    different   security   levels.      The    scheduled  operations 
method   insures    all    data    per    security    level   is   processed   at 
separate    times.      This   restricts    users    of   different   security 
levels   tc   computer    availability.      The   most    difficult   aspect 
to   this    aethcd   of   secure    processing   is   the    sanitization 
necessary   between   security    level    processing   periods.      The 
entire    system   environment  must   be    modified,    both    the    machine 
and    physical  facility.      In    addition,    communications   lines 
must    be    broken,     disk    packs    must    be  exchanged   for   the   diffe- 
rent   security   levels,   and   main    memory   cleared.      This 
procedure    averages    one  to  two   hours    to    complete.      [Ref.    5: 
P.    28] 

The    third  alternative,    system-high    security   operations, 
is    primarily  ised   throughout   the    WWNCCS    community.       with 
system-hiqh   operatiors*    ail    personnel,    physical    space,    and 
equipment   must    be   approved    for   the   highest    security    level   of 
the    information    being   processed.      The    biggest    disadvantage 
to    this    root  hod    is   the   restriction    it    places   on   the    sharing 
cf   secure    cciputer    resources.      In  addition,    this    method 
becomes    costly    in    terms   of    physical    security    and    personnel 
clearances.      The   system-high    security   approach,    if    imple- 
mented  correctly,    will  satisfy   security    level    requirements 
but    dees    not   address    the   need-to-know   issue.      [Ref.    5:    p. 
28] 

E.       HAEDH1BE 

The  availability  of  an  electric  power  source  greatly 
affects  the  reliability  and  survivability  of  a  computer 
network  such  as  the  WWMCCS  Intercomputer  Network  (WIN).   For 
the  current  WIN,  there  exists  nc  standard  criteria  for  the 
availability  of  electric  power.   If  electric  power  is 
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disrupted   cr  the   air-conditioning    damaged,    data    processing 
capabilities  are  totally   lost   or,    at    a    minimum,    severely 
degraded.      Only    a    few   WIN    sites    have    a    reliable    backup    power 
source   or   redundant    computer   system.      The   National    Military 
Command   Center    (NMCC)    maintains   two   independent    power 
sources    for   its    computer   system.      This   system   affords 
protection   against    various    lccal   power   blackouts    and    irregu- 
larities   in    the    commercial    power    system.      [Ref.    5:    p.    29] 
The    NMCC    alsc   maintains   a   totally   redundant    computer   system, 
hardware    and  software,   located   at   the   Alternate   National 
Military   Command  Center    (ANMCC)  ,    which    has    an    internal    power 
generating   capability.      In    early    WWMCCS    years,   the   ANMCC    was 
considered    hardened    and    fully   self-supporting,    but   the 
alternate   site    is    nc    longer    considered    hardened    against   t he 
current   threat.       A    few  other   large  WWMCCS    sites   utilizing 
commercial    power  are    also  armed    with    an    internal    power 
generating    capability,   for    instance,    the   North   American   Air 
Defense   Ccmicand     (NORAD)    and    the    Strategic    Air   Command    (SAC)  . 
Most    ether    WWMCCS   sites   have   no    reliable   backup    power 
source. 

Presently  the    NMCC  has,    of    course,    the    most    viaole 
altS'rnate   computer    system  —    both   redundant    and    remote. 
Other    sites    maintain    redundant   data    bases   but   usually    in 
close    proximity.       For    example,    the   Joint    Deployment    Agency 
maintains   a    backup    JDS  data    base    at    the    Readiness    Command 
(REDCCM)     but   which    is   physically    located   at    the    same 
facility. 

C.       ITJY    LEAGUE    82 

During    the    period    1    March    to    5    March    1982,    the    JCS 
conducted   a    WWMCCS    exercise,    IVY    LEAGUE    82.      The    exercise 
was    designed  to    evaluate   defense    operations   run    from    the 
NMCC    at    the    Pentagon,    then    relocated    to    the   alternate 
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command    center,    the    ANMCC.       As   the  exercise    progressed,    WIN 
performance   dropped   and   response    times   reached  an 
unacceptable   level.       A  DCA/CCTC    sponsored   IVY   LEAGUE 
Analysis   Task  Force    vas   organized    to    analyze   the    performance 
of    the    WWMCCS   ADP   system    and   network,    with   concentration    on 
the    particular    problems   encountered   during   the  IVY   LEAGUE 
exercise-      [Bef.    22:    p.    1-1] 

The    Task  Force    focused    its   analysis    on    the   four    major 
sites    where   the    slowdown    condition  was    most    prevalent:    the 
NMCC    Beadiness    Systerr,   the    ANMCC,    REDCOM,    and  the    JDA. 
These    four    sites    were  not   all  the    WIN   nodes    participating   in 
the    exercise,    but   it    was    felt,   these    sitas    were   indicative    of 
overall    WIN    performance   during   IVY  LEAGUE    82.      Information 
was    collected   from   on-site    exercise    personnel,   manual   legs 
updated    throughout    the  exercise,    computer    generated    list- 
ings,   and    WWMCCS   computer  system   console    legs   from    the 
participating  sites.      [Ref.    22:    p.    v  ] 

The    IVY    IEAGUE    Task    Force  revealed   several   major    factors 
contributing  to    the    WIN   degradation: 

(1)  excessive  communications    processor   loading 

(2)  communications    subnetwork    fragmentation 

(3)  host   computer   resource   contention 

(4)  software   resource  contention 

(5)  management  of  computer  operations 

Each    cf    these   will    be   discussed    in  the    following    sections 
with    their    impact   on    JDS    performance. 

D.       CCHHUHICATIONS    PBCCESSOR    LOADING 

The    successful    operation   of    the    WIN    network    depends   on 
an   unconstrained   flow   cf    data   between    the    computer    system 
and    the    network.       A    communications   processor    is    used   on    the 
network   to    coordinate   inputs   from   remote    terminals    and   send 
them    to    the    host   system;    it    also    receives    outputs    frcm    the 
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computer    system    and    sends   them   to  the   correct   user.      The 
communications    processor  handles   the    connection    from   the 
host    computer  system   to   the    network.       The    Honeywell    Datanet 
355    (EN    355)    is    the    communications   processor   used    throughout 
the    WWMCCS   community. 

The   design    cf  the   Datanet  requires    sufficient    available 
memory    to    process   message   traffic;   otherwise   the    Datanet    may 
restrict   the  flow   of   traffic   from  the    host    to  the    network 
and    from   remote    sites  to    the   host   througa    unsatisfactory 
terminal    response   time  and    slow    file    transfers.      The   block 
cf   memory    allocated    for    message    processing    is   subdivided 
into    sections  called    buffers.      Buffer   size    is   dependent   en 
the   type   and  number    cf  connections  to   the    Datanet.      The 
greater   the    number    of  connections,    the    lower    the    available 
memory   and    the    lower    the    buffer    size.       WIN    connections    to 
the    Datanet    must   contend    for   buffer    space    with   remote 
processors,    AUTODIN    connections,    and    the   local  terminals. 
[Ref .    22:    p.    2-1  ] 

During    ivy    LEAGUE   32,    when   the   Datanet    became    over- 
loaded,   users   experienced   up    to    ten   second   pauses    for   system 
response.      Seme    of    this    was    attributaole   to    Datanet    cver- 
conf icuraticn  --    too    many  connections    to    one    Datanet.       At 
JDA,    all    115   local    terminals    and    the    WIN    connection    were 
served    by   the  one    Datanet.       In   some    cases,    several    terminals 
shared    one    line    into    the    communications    processor    which 
further    hindered   terminal  response  time.       In   addition   to    the 
terminal    overloading,   this    same    Datanet    also    served   the 
AUTODIN    interface   at    all    four    sites    reviewed.      [  Bef  -    22:    p. 
2-1]    With  this    Datanet   configuration,    any   terminal   discon- 
nect   from   the  system   or   any    Datanet    failure   affects    all 
connected   terminals,    both   local    and   remote.      Considering   the 
large    number  of    terminals   connected,    the    chance    of    a    Datanet 
failure    or   system   reinitialization    (reboot)    to  clear 
terminal    or    WIN    problems   is    extremely   high.      Figure    4.1 
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graphically    depicts    user-dependence    on   the    DN   355/Host    link.. 
[Ref.    8:    p.    3] 
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Figure    4.1         JDA  Configuration. 

During    periods    of    particularly  bad   performance    in   IVY 
LEAGUE    82,    cemputar    data    dumps    wera    taken    from   the    REBCGM 
Datanet.      JEA   Datanet    dumps    were    not    available,    but    the 
REDCOM    configuration    was  considered    similar   to  that    of    JD& 
with    139    local    terminals    connected  to   the   one   Datanet.      Data 
retrieved    revealed    4,490    data    transfer    requests    denied 
during   a    17-hour   period    because    of    insufficient    buffer 
space.      During    a   separata   22-hour   period,    an    additional 
U,651    data   transfers    were   d =nied    due    to    lack    cf    buffer 
space.      These   nuibers   only    reflect  Datanet    denials,    local 
Interface    Message   Processor     (IM?)    and   terminal   malfunctions 
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may    also    have   occurred.      During    IVY    LEAGUE    82,    the    JD<\    hcst 
computer   received   an   average   of    150,000    transactions   per 
day.      Specifically,    en   2    March,    JDA   processed    252,864   tran- 
sactions   and  87,U17    transactions    were    processed    en    u.    March. 
[Hef.    22:    p.   2-2] 

Another   hinderance  to  Datanet   performance   was    operator 
reboots   cf   the    Datanet.      Operations    would    frequently   reini- 
tialize   the    Datanet    in  an  attempt   to    free    blocked   terrcinils 
or   solve    WIN  problems   and  various   other    abnormalities    cccur- 
ring    in   the    network.      [Ref.    22:    p.    2-1]    Although   the 
specific    impact    cf    these   Datanet   restarts    were  not    analyzed, 
they    cbvicusly    affected    WIN    performance.       For   instance,    the 
Joint   Deployment    System   tranfers   TPFDD   files   and    TPFDD    file 
changes    tc    remote    sites   through    the    WIN   FTS.      If    a    Datanet 
reboot   occurs  during   this  time,    the   file   transfer    must    be 
recovered.      Previous    to   the    development    of   the   Remote    User's 
Eackage    (EUP),    transaction    recovery    meant    file  transfer 
reinitialization.      Now,    the    JDS    Update   Processor    (JDSUE) 
dynamically    generates  checkpoints   throughout    the   transfer    tc 
allow   file   transfer    recovery   at    the   point    cf    disconnection. 

The    WWKCCS    cemmunity    employs   Datanet    performance    moni- 
toring  software    to    warn    of    possible    Datanet    overload.       This 
monitoring   software    requires    approximately    2,500    words    cf 
memory    which   further    reduces   the    Datanet   memory    availaoici 
for    nessage   processing  buffers.      Consequently,    at   all    four 
sites   included    in   the   analysis,    the    monitoring  software   wis 
net    in   execution.      [  Bef .    22:    p.    2-1] 

E.        NETWOBK    FRAGMENTATION 

As    discussed   in    the    previous    section,    the    WWMCCS    network 
is    very    susceptible    to  interruptions    cccuring   within   the 
lines    cf    ccmmunicaticns.      Any   network   configuration    changes, 
component   outages,    or   circuit    failures    will   cause 
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fragmentation   of   the    network   into   subnet works ,   thus 
degrading    performance.      [Ref.    22:    p.    3-1]    Each   »WMCCS    hcst 
computer    involved   in    the    WWMCCS    Intercomputer   Network   is 
linked   tc   a    Honeywell   minicomputer  called   an    Interface 
Message    Processor    (IMP),    and   the    various    IMPs   are    then 
interconnected. 

During   IVY    LEAGUE   82,   the   Network   Operations    Center 
(NOC)    and   BCA  Operations    Center    (DCAOC)     were   relocated    to 
the    alternate  command  center,    the    &NMCC.      To    provide 
continued   support    for  these    nodes   on    the    WIN   subnetwork,    the 
master   IMF,    normally    at   the    Pentagon,    was   logically   recon- 
figured   tc   the    backup   facility  at   the    Command   and   Control 
Technical   Center    (CCTC) ,    Reston.      Changes   were   necessary 
within   the    WIN    subnetwork  due   to    the    backup   IMF's    limita- 
tions   and   circuit   availability.       The    major    modification   was 
the    deletion  of    the    link    from   the   master    IMP    to   the    IMP    at 
Headguart ers,   Atlantic  Command.       As   the   exercise    progressed, 
it   became   evident   that  the    loss    of  this    one   particular    link 
proved   tc   be  a    major    factor    in   network   fragmentation  * 
During    these   periods    cf    fragmentation,    the    exchange   of    data 
between    WIN    sites   was   totally   disrupted.      [Bef*    22:    p„    3-2] 

Although  the   IMP    and   circuit   outages    were   usually   short, 
these,    ccupled    with    the    major  configuration   changes, 
severely    degraded   WIN   performance.      For   instance    en    2    March, 
88    circuit   outages    occured    for    a   total   cf   5.13   hours 
down-time.      Later   in    the   exercise   on    4    March,    a    sum    loss    of 
7.72    hours    uas    felt    during    138   circuit   outages.       For    the 
entire   IVY    LEAGUE  82    exercise,    476   line    outages    occured    with 
65    extending  over    10    minutes,    22    of    these    outages    were    the 
result   of   reguired    cryptographic    key    changes.      Key    changes 
were    a    freguent    cause   for  circuits  displaced    from    normal 
activities.      IMP   outages    for   the    exercise    totaled    334    with 
52    lasting    ever    10    minutes:    77   at    6.63    hours    en    2    March   and 
82    at    7.62    hcurs   on    4    March.      [Ref.    22:    p.    3-6] 
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F.       BESOOECE   CONTENTION 

During    IVY    LEAGUE   82,    numerous  cases    of   host    resource 
misuse    occurred    in    areas   such  as   primary   memory   allocation, 
job    priority  assignment,    and  improper    implementation    cf   WIN 
software.      These   conflicts    severely    11 mi  tad   the    host   system 
performance.      The   Analysis    Task    Force    studied  these   prctlems 
at   the    NMCC    Feadiness   and   ANMCC    computer   systems    only,    but 
it    was    felt    similar    situations  existed   at   numerous    ether 
UWMCCS    sites.      [Bef.    22:    p.    4-1] 

The    NMCC  WWMCCS    site   is    segregated   into   two   distinct 
computer    systems:      Readiness   and    Support.      Thr:   Readiness 
System    is    designed    fcr  the    operation    of    HWMCCS    standard 
software    and  other    site-unigue   software    that    has    previously 
teen    tested    and    is    new  in   production.      The    NMCC    Support 
System   is   an  identical  configuration    to    the   Readiness    system 
and    exists    fcr    the    development   and  testing    cf   new    software. 
Cnly    the    Readiness    System   participates    in   JCS    exercises   as 
the    Support    System    continues   to    support    daily   operations. 
Priorities    fail    so    that   the    Support    System    may    be    sacrificed 
to    maintain   the    performance    of   the  Readiness    System. 

With    cnly   fully    operational    software   allowed   on    the    NMCC 
Readiness    System,   the   percentage    of   aborted    jobs    is    expected 
to    be    small.      During    the    exercise,    the    amount    cf    computer 
resources    expended    cr.    jobs    which    ultimately   aborted    was 
unacceptably  high.       Some    aborts    were    due    to   magnetic   tape 
and    various    ether   hardware    problems,    out    an    undesirable 
number    were   caused    by  software   still    in   the   developmental 
stags.      [Bef.    22:    p.    4-2]   Prior    to   a    new    WWMCCS    software 
release,    the  temptation   for    programmers    to    use   the   Readiness 
System    as    a    testbed    fcr   application    system    modifications    is 
high.      The    response    time    is    decidedly    better    en    the 
Readiness    System   because   of    decreased   aDorts    and    code   optim- 
ization.     Guidelines    for   testing   state   all   systems   resident 
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on    the    Readiness  system   to    be   tested    and/or    modified    will    be 
transferred   to   the    Support    System.      After    verification    with 
the    new    WWMCCS    software,    the   modified   system    will    then 
replace   the   old    systen  on   the   Readiness   computer.      The    idea, 
of   course,    is  to   preserve  the  Readiness    computer    in    both 
time    and    space    requirements    for    crisis/exercise    support   and 
employ   a    second    system  for    the   heavy    processing    and  the 
usually   large  space    consumption   of  software   development. 

Beth    systems   studied,    the   HMCC   Readiness    and    the    ANMCC 
system,    suffered   froB  a    lack  cf   availaole    memory    for 
processing.      In    particular,    on    2    Karch   memory   shortages 
severely    cor.strained    processing    capabilities    for    a    five    hour 
period.      Under    the    current    WWMCCS   ADP,    it    is    possible    tc 
dynaiically    reconfigure  a   system    without   completely    bringing 
it   off-line;   for   example,    allowing  the   addition   of    memory   to 
the    best    computer   system    during    an   exs::cise.      [Ref.    22:    p. 
1-1]    fllthcugh   infreguentiy    done,    memory   may    be   acquired    from 
the    NSCC    Support   System    to    improve  the    performance    cf    the 
Readiness    System. 

A    standard    WWMCCS   program   size   is    cipproximately    60K    (60 
x    1024    bytes).       Any    cne    application    program   requiring    mere 
than    6 OK    or    a   large    amount    of  CPU   time,    should    be    remodeled 
to    include    code    optimization    and    some    iiethcd    of    memory 
overlays   or    paging.      [Ref.    22:    p..    <*- 1  ] 

In   addition    to    large    memory    utilization,    numerous    jobs 
with    high    priorities   running   simultaneously   will    affect 
system    performance.       Honeywell   supports    an    urgency    system 
for    determining    job    priorities   --   urgencies   may    vary    from 
zero    to    63.      Typically,    urgencies   of    30    and    below    are    used 
for    user   application    programs;    for   example,    routine    batch 
and    TSS    jobs  are  assigned  an  urgency    of   5.      Urgencies   above 
30    are    reserved    for    system    software    applications    and   special 
production    runs.      Urgencies    higher  than    50    support    system 
programs    such   as   TLCP,    FTS,    and    other    WIN    software. 
[Ref.    22:    p.    4-2] 
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Statistics    show    approximately  thirty    percent    of    all 
activities    processed    en   the    ANJ1CC  computer   system    during   the 
exercise    had  urgency    levels    greater   than   or   equal   to    the 
urgency    levels    of   system   functions.      Software   such    as    1SS 
and    WIN   have  urgencies  from    50    to  60    to    allow    primary    access 
to   the    prccessor.      During   IVY  LEAGUE    82,    this   software    was 
competing   with    user    application    software    for   computer 
resources   because  of   unjustified   high   user    application 
urgencies.      [Ref.    22:   p.    4-1] 

The    KWHCCS    systen  consols  operator   has    the   ability   to 
override    system    prescribed    urgencies.      This   is   usually 
accomplished  on    a   case   by   case    basis    for    ad-hec    production 
runs.      Any   systeir   reguiring    a    large    block   of   memory, 
substantial    CPU    time,   or    lengthy    input/output   processing 
will    normally  be   awarded   a    lower    urgency,    causing   it   to 
remain   in   the  system    a  relatively   longer    length   of   time. 
When    the    urgencies    of   these    systems   are    bumped  to    higher 
levels,    whether    justified  or   not,    they    compete   with    system 
software,    usually   large    time-consuming    systems   themselves 
and    the    •rrolasses   condition'    occurs   --    total    system    slow- 
down.     An    inordinate   amount    of    automated   bookkeeping   is 
necessary    fcr  proper    resource  availability   and  the   processor 
becomes    overloaded.       When  this    condition    occurs,     known    as 
thrashing,    the    effectiveness   of    the    Honeywell    urgency   system 
drops    to    zero. 

The    cumulative    affect   of   all    the    above    mentioned   situa- 
tions   equals  increased  user    response    time    and   user 
frustration.      During    normal    NMCC    operations,    TSS    response 
time    averages   five    to   seven    seconds;     during   heavy    usage, 
exercises   or  crises,    response  time   increases    incrementally 
by    approximately  three   seconds    until    total    system    slowdown 
occurs. 
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WIN    software   is    ret  always   the    'victim1    of   poor    WIN 
performance.      Some    software,    both  systems    software    and 
application    systems,    contribute    to  the   increase    in    host 
system   processing  requirements.      When   these   requirements 
exceed   system  ca [abilities,    support   of   local    and   network 
operation    decreases. 

Seme    of   the    fcIN    system    software    particularly    affected    by 
degraded   network   performance   includes: 

(1)  Teleconferencing    (TLC?)     System 

(2)  File   Transfer   Service    (FTS) 

(3)  Tele  com  inundations  program    (TELNET).      [Ref.    22: 
p.    6-1] 

The    Teleconferencing    capability    in    WIN    allows   users    tc 
rejoin    the   conference  and   request  a   transcript   file   of 
actions    since   that    site's   las-    log-on.      These    files    are 
spooled    to    the    printer  at  a    high    urgency    for    speedy 
printing.      During   IVY  LEAGUE   82,    the    large   number    of   tran- 
script   file    requests    severely  impacted   the    performance    cf 
the    system    hosting    the  teleconference. 

The    File   Transfer   Service   employed   in    the    WIN    utilizes   a 
dynamic    memory    management   scheme   to    maintain   an   available 
memory    level  between    the    minimum   and    maximum    guidelines. 
The    management    system  constantly    allocates    and   deallocates 
sections    cf    memory    as  small    as    1K    to    sustain    an   acceptable 
memory    level.      Th:.s    continuous   processing   requirement   places 
a   heavy    lead  on    the    host    processor.       Also,    during    a    file 
transfer,    FTS   reads    and    writes   one   Little    Link    (LLINK)     cf 


data    a 


+     a     +■  t 


ima,    320    wcrds.       This    limits    possible    transfer 


rates   and   FTS   effectiveness.      [Ref.    22:    p.    6-1] 

TELNET    uses    software    similar   to   the    FTS    memory    manage- 
ment   software.       Although   this  imposes   additional    loading   on 
the    processing    system,   the    contribution    to    system    leading   is 
not    as   significant   as  FTS   or  TLCF.      [Ref.    22:    p.    6-1] 
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G.       JES    BESCORCE   CONTENTION 

Large   software   applications    used    over   the   "rfWMCCS 
network,    such  as   the   Joint    Deployment   System,    need    tc    be 
concerned   abcut    resource   requirements   and   operational   effi- 
ciency.     Since    such    a  wide    degree  of    diversity   exists   among 
application    systems,    no   guidelines  for    standardization    of 
new    WSMCCS    software    have   been    established;    therefore,    these 
issues    are   left    to    the  developing   agency.      For   instance,    the 
Joint    Deployment   System    maintains   two    interactive    subsys- 
tems,   the   JDSIP    and    JDSUP  as   part   of    the    3emots   User*s 
Package    (BOP).       The    Analysis   Task    Force    contends    these    two 
subsystems    fail    to   take   the    best   advantage   of   the    standard 
WWMCCS   software    features    and   consequently    generate    substan- 
tial   overhead   for   the    processor.      After    analysis    of    IVY 
LEAGUE    82,    the    need    was    evident    to   redesign    portions    cf    the 
JDS    scf-cwar^  to    insure  more    efficient    processing    and 
overhead    ninimization.      [Ref.    22:    p.    6-3] 

The    operation   of   the    JDSIP    caused   noticable    degradation 
durinc   the   exercise.      The   Interface   Processor   subsystem 
requires    28K  to    process   and    runs    with    an    urgency    of    51.       The 
JDSIF    will    remain   in    memory    as    long    as    it    is    processing 
transactions.      When    the    processor  is    not   required,    i.e.,    no 
transactions  to    be    processed,   the  JDSIP   will    place    itself   in 
a   'sleep    state1     —    degrading   its    urgency   to   zero    which 
immediately    allows    it   to   be    swapped    out    of    the   system   at    the 
next    scemory   allocation  request.       Actually,    this    should    be 
very    efficient    use    of   memory,    or    at   least    28K.      The    problem 
arises    in    waking   up    the    JDSIP.       Since   the    subsystem    has   no 
leans   cf    determining    when   the   next   transaction   will    be 
received,    the  JDSIP    periodically,    abcut   every   two    tc    three 
seconds,    resets    its    urgency    back   to    51    which    returns   it    tc 
memory    where   it    can    check  for   transactions    to   be    processed. 
If   no   transactions    are  waiting,    the    urgency  is  returned  to 
zero    and    the  cycle   repeats.       [3ef.    22:    p.    6-3] 
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This    scheme    is    at   its   worst    when    JDS    is   rarely    used   on   a 
given    system.      The    JESIP   simply    fluctuates    from    mass    storage 
to   primary   memory   with   no  advantage.      This    swapping    back   and 
forth   creates   unnecessary  overhead  processing   and    can    seri- 
ously  degrade  network   performance.      Case   in   point:      en    1 
March,    during   IVY   LEAGUE   82,    the    JDSIP    was    swapped    a    total 
cf   412    times  in    an    eight-minute    period,    from    1355   to    1403. 
[Ref.    22:    p.   6-3  ] 

The    JDS    Opdate    Processor    (JDSU?)     poses    a    similar   situa- 
tion.     The    JCSUP  requires   only   9K   to    process    and    runs   at    an 
urgency    cf   55.       During  certain    processing    periods,    the    JDSUP 
must    request  a    single   block    cf   50K  of    memory.       When    this 
regusst    enters    the    system,    the   system    will    immediately    rear- 
range   its    memory    to    accommodate    the    request    from    such    a   high 
priority    jot.      Usually,    a  system    interruption    is    evident. 
A:ter    the   JDSU?    has    completed    that   process,    the    50K    is 
returned    to    memory;    however,    the    JDSU?   in    general    immedi- 
ately  asks    for    another  single   blcck   of    50K   to   continue 
processing.      [Ref.    22:   p.    6-3] 

The    allocation    ard  deallocation    of   this    50K    of    memory 
proved    to    be   detrimental    during    the    IVY    LEAGUE  exercise.      On 
2   March,    JDSUP    requested    50K    at    0120,    released  the    memory   at 
0'122,    and    requested    another    50K    block    at    0125.      This    cycle 
cf    r equest-release-r eguest    was   repeated    during  the    0330-0340 
time    pericd    that   same  day.       [Ref.    22:    p.    6-3] 

H.       SA8AGEHEBT    OF    COMPUTER    OPERATIONS 

During    IVY    LEAGUE   82,   it   became    evident   that    hardware 
and    software  problems   were    net    entirely    responsible    for    the 
C3   system   degradation.      The    overall    management   and   control 
of    the    network    and    host   system    also    contributed   to    deficient 
performance. 
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As   part   of   the    normal  opera-ions    of    all   WIN    sites,    hard- 
ware   such   as  the   host  computer   system,    the    Datanet,    and   the 
IMPs    are   reinitialized  in   an   attempt    to    solve   various    prob- 
lems.     These  reboots   interrupt   network   performance    and    can 
impact   local  user  operations.      In   addition   to   unexpected 
down    time   and   reboots,   scheduled    outages   occur   at    all   sites. 
The    WKMCCS    community    has    no    standard    guidelines    for    the 
scheduling   cf   these    outages.      Frequently,    these    unscheduled 
downtimes   are  not    justified;    for    instance,    during    the    exer- 
cise,   a    Datanet    was    rebooted  to    allow   a    single   user   access 
to   a    particular    system  for   a    local   processing   requirement. 
This    reboot    affected    all   users   on   that    subnetwork. 

On    3    March,    the    ANMCC  discontinued    service   to    remote 
users    because   of  an    apparent   memory   shortage    problem. 
According   to  VIDEO,    an  online   display    system    which    allows 
monitoring    cf   system    status,    minimum    work    was    being 
processed   because   of    a  lack    cf    available    memory.       The    after 
exercise    analysis   however,    revealed    approximately    150K    cf 
memory   available   during  that    time    frame.       The   discrepancy 
occurred    due  to    improper    use   of    the    VIDEO    system.      This 
system    is    designed    tc    provide   an    instantaneous   picture    cf 
system    resources.      The  system    was    likely    restructuring 
memory    to    accommodate    the   increased    wcrklcad    when    the    deci- 
sion   was    made  to    detach    all    remote   users.      [Ref.    22:    p.    5-2] 

Another   operational   contribution    to    poor   network   perfor- 
mance   occurred    when    5TS    was    used   to    transfer    files   around 
withir.   the    same    site,   as    opposed    to    using    a   COPY    utility. 
Transferring  a    file    with   sending   and    receiving   sites    speci- 
fied   as    the    same   sit€,    sends   the    file    to    the    local    IMP    which 
immediately    returns    the    file   to    the   same    host.      During    IVY 
LEAGUE    82,    exercise    statistics    showed    that    342  of    ail    file 
transfers   at  the   NMCC  were    same-site    transfers,    as    were   6  7% 
cf    Military    Airlift    Command     (MAC)    transfers   and    833    at    the 
WWMCCS    site    supporting  the    Commander-in-Chief,    Naval    Forces 
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Europe.   [Ref.  22:  p.  5-3]  This  type  of  functional  misuse 
wastes  best  system  resources  and  contributes  to  WIN  loading, 
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V.     RECOKMENMIIQM    AND    CONCLUSIONS 

When    the  current    WWMCCS/WIN    management    problems    are 
addressed   during  the   modernization   phase,    network    perfor- 
mance   should  improve.      This    will   decrease   user   frustration, 
especially   during   high  volume   times,     and   increase    user 
activity    en    the    system.      This   increase   in    volume    in    turn, 
may   affect   system   performance  and,    with   greater    user    parti- 
cipation  comes   additional   site- unique   software.      Site-unique 
applications  are  created   due  to    deficiencies   within   the 
system    which   will   always    exist    in   a    system    as    large    as 
WWMCCS.      The  WIS    modernization    plan    does    not    propose   to 
eliminate   this    unique   category    of   WWMCCS    software,     just 
minimize    its   proportion   to    standard    software. 

A.        SOFTWARE 

The    WIS    modernization   plan    includes   a    new   operating 
system   release,     GCOS    8.0,    and   a    modified    Honeywell    main- 
frame,   the    H6000   Distributed    Processing    System    (DPS). 
The    major  software  modifications    include: 

(1) improved    data   management    and    timesharing 
processing 

(2)  DPS    software   written    in    a    high    order    language 
which  facilitates   maintenance    and   modifications 

(3)  increased   number   of    timesharing   users    from    200 
to    600 

(4)  increased   number   of    concurrent    processes    from   64 
to    511    [Ref.    23] 

Net    mentioned   in    the   WIS   modernization    plan    is    ary    just- 
ification  that    this    increase    in    possible    user   activity    will 
not    further    degrade    system    performance.      Although    a    new 
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processor   is  under    consideration,    the   H60QQ   DPS    modifica- 
tion,   a   significant    increase   in    processing    capability    is 
already   critical  to    maintain   availability   cf    present    WWMCCS 
software.      Increasing   the   number   of   time   sharing    users 
three-fold   will    cuickly   com sume    any   available   processing 
time . 

The    WWMCCS    modernization    plan   also   includes    the    CM4 
software    package   for    tetter    file   management,    allowing   diffe- 
rent   file    structures    for   files   in    the   same    data   base,    and   an 
enhanced    DBMS,    the    Integrated   Data   Store    II    (IDS    II)  ,      With 
the    current    IDS    I,    the   progammer    is    not    independent    cf    the 
data    tass  --   one   of    the    fundamental   requirements   of    e.    Data 
Ease    Management    System,      when   using    IDS    I,    the   user    must 
know    the    data   base    layout,    referred    to    as    the   schema,    and 
must    include  various   system    routines    to    successfully    update 
the    data    tase.       IDS    II   will    be    more    cf   a   true   DBMS,    allowing 
user    independence   from  the    data    base   schema. 

With    a    true    DBMS,    more    users   are    likely   to   pursue    infor- 
mation  contained   within  the    system,    thus   increasing   user 
retrievals    from    remote  sites,    i.e.,    retrieval  requests    from 
the    JCS,    and   increasing    data    transfers   on    WIN.       Again,    the 
WIS    modernization   plan   lacks    an    apparent    knowledge    of    acw   to 
handle    this    increase    in   activity. 

Although  the   basic  software    design    of   the   WWMCCS    equip- 
ment   is    inadequate    for  a    Multi-Level    Security    (MLS)    system, 
there    has    been    a   proposal   using    hardware    modifications. 
Honeywell    has  developed   a    system,    the    Honeywell    Secure 
Communications    Processor    (SCOMP) ,    which    runs    on    the 
Honeywell    Level    6    minicomputer    and  is    billed    as    a    MLS 
system.       SCOMP    utilizes    four   rings   of    protection    with   the 
kernel   residing    in    Ring    0   and  the   least    priviledged    ring, 
Eing    3,    belcnging    to    the    users.       But    SCOMP    also    modifies   the 
hardware    fcy    supplying   a    hardware    segmentation    capability    for 
dividing    main   memory    into    distinct   logical    (net    physical) 
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areas.      This  should    allow   access    checking    cer    segment    for 
read/write    priviledgss,    thus   maintaining   controlled   software 
sharing   among  many    users.      [Ref.    24:    p.    4] 

Whil€   SCCMP    has    not    been    fully   validated   by    the    DOD 
Computer    Security   Center,    part    of   the   National    Security 
Agency    (NSA) ,    it   is    considered   a    large   step   towards    the 
secure,    time-shared    computer   resources   needed    in    cemmunit ies 
such    as    the    WWMCCS    community.      In   December     1931,    the 
security   center    published  a    Product    Evaluation   Bulletin 
specifying   that    SC0J1F   "...    should   be    considered   an   accep- 
table  candidate    for    a   wide    range    of    minicomputer 
applications   which    require    an    enhanced   architecture    to 
suppcrt    secure    processing  requirements."      [Sef«    25] 

Accther    emerging    alternative    is    the    ELACK2R    Technology. 
ELACKER    will  supply    end-to-end    encryption    through    the 
ELACKER   Terminal    Access   System    (TAS)  .       This    IAS    is    a    PDF 
11/70    or    PDF    11/34    ard  acts    as   a    buffer    be -ween    the    network 
and    hest    computers    for  security    verification.      Upon    leg-on, 
each    user    will    be   assigned    a   one    time    key    for    the    life    of 
the    terminal  session.      These   keys   will   be   checked   and    veri- 
fied   before    access    tc   each    data    base    is    allowed.       They    will 
also    be    used  to    control   inadvertent    misrouting   of    ia*a, 
referred    to    as    spillage.      [  Ref .    26:    p.    6  ] 

The    main  idea   behind   the    BLACKER    prototype    is    tc    allev- 
iate   the    burden    cf    numerous    passwords    for    each   user    per    each 
host    computer.       Passwords   are  no    longer    considered    secure 
for    seme    classif icat icn   levels   because   they   must    be    stored 
within   the   computer    system    and   users    frequently    violate 
security    procedures    by  writing   them   down.      One   of    the    mest 
viable    alternatives    proposed    has    been    the    use   of    magnetic 
strip   identification    badges    and   electronic    badge    readers. 
This    system    would  allcw   for    minimum    manual    intervention. 
[Ref.    26:    p.    17] 
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A    MLS   system   would  allow  the   Joint    Deployment    Agency    to 
control   access    tc   various  capabilities   in    specific   OPLANs. 
Presently,    all    host    computers   and   personnel   mast    be    cleared 
to   the    highest    security   level  of    any    piece   of   data   contained 
in   the    OELAN. 

Functioning    without    a  MLS  system,    full    utilization    cf 
WWMCCS   resources   is    improbable  and  the    sharing   of    comput-r 
resources   over    the   network:    is   restricted.      During   the 
interim    between    the    present    security    procedures    and   the 
eventual    development    cf   a  MLS  system    for    WWMCCS,    the    WIS    JPM 
becomes    the   central    WWMCCS    security    officer   to  standardize 
physical    security   procedures  and   set    guidelines    on    the 
handling    cf   different   security    levels   on   the   same    machine. 

E.        HAECWAHE 

The    WIS    modernization   plan   does   not    address   the    issue   of 
redundant    power    supplies.       The    vulnerability   of    computer 
hardware    to    electric    power    for   operations    and    support,    i.e., 
air    conditioning,    is    immense.      With    very    few    WWMCCS    nodes 
having   a   reliable   backup   power   source,    the   network   should 
not    be   considered  survivable. 

Included    in    the    rear-term   WIS    modernization    program    is 
the    procurement    of   the  Honeywell    6000   Distributed   Processing 
System    (DPS)    modification.       The    H6000    DPS    offers    major    hard- 
ware   and    software   improvements   over   the    K606Q    and    H6080 
equipment   currently    used    in    the    WWMCCS    community.       Major 
hardware    changes   include: 

(1)  70%    to    90^  increased    processing   speed 

(2)  space,    power,    and   air-conditioning  requirement 
red  uct  ions 

(3)  three-ring  architecture    for    MLS   system    possi- 
bility   [Bef.    23] 
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The    Honeywell    mainframes   presently   used  are    fas- 
approaching   the    age    of  computer   antiquity.      The    largest 
problem   centers   around  the    Hor.syweLl    architecture    which   was 
not    designed  to    support   an    online,    interactive   environment. 
When    hardware   replacement   is   considered,    the    WWMCCS    host 
computers   should   be    replaced    with   computer    systems    designed 
to   support    a  real-time,    online,    interactive   environment. 

The   changing   requirements  for   :ietwork    software,    moving 
this    software  onto    the  Datanet    processors,    and  advancements 
in   computer   technology  have    all    reduced    the   mainframe 
requirements  for   most   WWMCCS    sites,       For    hardware    acquisi- 
tion,   WHMCCS   sites    will   consider   a   series   of    minicomputers, 
for    instance  the   Honeywell    Level    6   minicomputers,    versus    one 
large    machine.       Of   course,    each    site    would    be   unique   in 
configuration   but   a    typical    WKKCCS   site    could   employ    one 
Level   6    for    each   of    the    following   i unctions:      tne    AUTOETN 
message    processing,    the   HI$    connection   to    include    handling 
TLCF    support,    the   ADF-LO    functions,    and   ail    resident    data 
bases   and   local    processing    requirements. 

C.       COMMUNICATIONS    PSOCSSSOH 

The    WwttCCS    community    has    communications    processor    moni- 
toring   software    which   consumes    2,500    words   of    Datanet    memory 
when    implemented    but    can    supply    valuable    information    en 
Datanst    overload   situations.      The   implementation    of   this 
monitoring   software    for   the    Datanet    is   not    a   requirement    for 
WIN    sites,    but    each    site    should    perform    a    trade-off    analysis 
on    memory   required    and  information  received.      The    statis- 
tical   output   froi  the   monitoring   software   could   reduce 
Datanet   reboots    by    notifying  operators   of    potential    weak- 
nesses   in   the  system;    i.e.,    running    out    of    buffer    space    for 
message    processing    or  the  number    of   transfer    denials 
exceeding    an  acceptable    level.      If   memory    space    cannot    be 
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supplied    during    a   crisis/exercise   situation   for   the    moni- 
toring  software,    controlled    simulations    using  the   Datanet 
monitoring   software    should    be   implemented   to   forecast   poten- 
tially  threatening    process    combinations   to   the  Datanet. 

A    set    of  standard   sy:-rtem  guidelines    should   be    develcpsd 
for    use    at    all    WIN    sites    to    establish    acceptable    criteria 
for    Datanet    reboots.      Frequent   rebooting   as   a    first    try   at 
solving    a    network    problem   should   be    discouraged. 

Also,    a    WIN    software   validation    package   should    be    devel- 
oped   tc    prohibit   file   transfers    within   the    same   site. 
Included   should    he    installation    checks   to    insure    WWMCCS 
Standard   System    Software    is   installed   properly   and   site 
cptiens    are    set    at    tbe   prescribed   level.      [Bef.    22:    p.    7-4] 

The    Catanet    cverconf iguration    problem,    i.e.,    115   termi- 
nals   linked    to    one    Datanet    at   JDA,    lends    itself   to    two 
recommendations.      The    first    solution    is    simple   but    rather 
expensive  --   procure    more   Honeywell    Datanet   355    processors. 
Ideally,    this   would    allow   one   Datanet    to    be    dedicated    tc 
that    site's    WIN    connection.      This  configuration    would   reduce 
WIN    problems  associated   with   operator    reboots   of    the    Datanet 
to    solve    ncn-WIN    problems.       [Ref.    22:    p.    2-2]   With    addi- 
tional   Datanets,    user    leal    could    be    better    distributed    and 
Datanet    failures    would  have    less    impact    on    the   site    perfor- 
mance .       At    a  minimum,    sites    should   avoid   linking    high    volume 
connections    such   as    BIN,    MJTODIN,    and   the    JCS    ADP    Liason 
Cfficer    (ADPLO)     terminals   on   the    same    Datanet.      In   addition, 
sites   should  adhere    tc  the    standard    WWMCCS   loading    levels 
for    the    Datanet    as    directed    by   the    WWMCCS    ADP    Advisory 
Memorandum    (WAAM). 

The    second    recommendation   is    to    eliminate  the    Honeywell 
communications    processor    equipment   and  transfer    these    func- 
tions   either  to    another   vendor   communications   processor   or 
to    a    minicomputer,    such    as    the   Honeywell   Level  6    minicom- 
puter.     The    Honeywell   Datanet   355    is    limited    in    a    memory 
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sizs    which    is  no  longer   sufficient   for   the   normal    message 
processing    capacity    at  large   WIN    sites.      Using  the    Lavel    6 
minicomputer  in    series  would   alleviate  the    memory    problems 
and    provide   additional  processing   capabilities. 

D.        HETWOBK    FRAGMENTATION 

To   prevent    the   reoccurrence   of  problems   similar   to   the 
cr.es    caused    by    the    Master  IMP  being    reconfigured    during    IVY 
IEAGUZ    32,    contingency  plans   should    be   devised  to    eliminate 
the    drastic   configuration  changes  as    were   necessary    when 
such    a    targetable   USE  was   deleted   from   the    network.       Studies 
and    crisis/exercise    ucnitoring   should   be    undertaken   to 
predict    possible   circuit    rr    IMP    links   which   could    initiate 
network    fragmentation.      [Ref.    22:    p.     3-9]    After    identifying 
these   areas,   they   shculd    ba    reinforced    during   high    volume 
times    by    redundant    configuration    or   specific   rerouting 
algorithms. 

After   the  C/30    switch   upgrade,    part    of    the   WWMCCS    moder- 
nization   plan,    IMP    and  circuit   outages    shculd    decrease.      The 
C/30    switch    will   provide    tandem    processing    of    up    to    3C0 
packets    per    second,    fcr    a   total    of   900    packets   being 
processed.      Routing    and   rerouting   will   ba   accomplished    by 
adaptive    routing   algorithms    which    will    reroute    individual 
packats    to    the    shortest    path.      In   addition,    monitoring    and 
control    functions   are   included   to   provide   fault    isolation 
and    hardware   and   software   problem   diagnosis. 

Replacing   the   huge  WWMCCS   network    with    a    series    of    local 
Area    Networks    (LANs)     will  alleviate    some    of   the    degradation 
felt    during    network    fragmentation.      Moving   the  network    soft- 
ware   from   the   Honeywell    mainframes   onto   the    Datanets    is   the 
first   step    in   building  independent   LANs.       Eventually,    all 
network    software   should   be    moved,    alleviating   the    mainframe 
from    any   network  control   responsibilities.      This    would 
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remove    the    restriction   for    standard   hardware    for    all    win 
sites.      With  no    standard   hardware   limitations,   users    could 
tailor   the   acquisition  of  new   hardware   around  specific    site 
requirements.      Since    all    host   systems    will    be   linked   through 
a  coalmen    network,    minimum   compatibility    problems    should    be 
experienced. 

E.        RESOOBCE   CONTENTION 

One    popular    recommendation    for  the    mainframe   processor 
contention    problem    is  the  addition  of   another    processor   fcr 
the    NMCC    Readiness    System.       This   additional   processor   would 
be    justified  during    an  exercise    but    not    fully    utilized 
during    daily  operations. 

As   opposed   tc   procuring    an   additional   processor,    the 
Support    System    cculd    be   modified    to   temporarily   provide   the 
necessary   hardware/scftware    equipment    during   crisis/exercise 
situations.      The    mair  advantage    to  this    plan    is   reduced 
swapping    ::or  CPU   contention.      [  Ref .    22:    p.    4-3]   The    validity 
of   this    plan  is    somewhat   questionable.       Previous    to   the    NMCC 
WWMCCS   computer    system  division   into* Readiness  and    Support 
systeros,    there    was    a    H6080    machine   with    two    processors.       CPU 
contention    reached    a    level    to   warrant    the   separation    of 
produrticr.    and    development    efforts,    thus    was    born    another 
computer   system    strictly    for   developmental    efforts. 
Configuration   now   stands   at    two    separate    systems    with    one 
processor   each.      As    lentioned   in   a   previous   section,    users 
do   not    always   respect   the   guidelines    for    use    of    these    two 
systems.      In  light    of   user-induced   problems   affecting 
performance,   stronger   enforcements  of    implemented    procedures 
would   be    more  cost- affective.      The   recommendation    fcr   an 
additional   processor    is    expensive   whether   the   dollars   are 
spent    actually    procuring   another    processor    which    will    be 
fully    utilized    only    about   twenty-five   percent   of    the    time   or 
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the    Support    System    software    is   used   for    high- priority    usage. 
During   the   later  option,    numerous  software   development 
personnel   with    no   planned  participation    in   a    crisis/exercise 
environment,    would    be    without  a    computer   processor    which 
greatly   restricts  their   developmental   efforts. 

Also   hindering   processor   performance   is   the   Honeywell 
urgency    scheme    for    processes.      The   basic   idea   of    the 
Honeywell   urgency   scheme   is    acceptable.      The   urgency    scheme 
needs    adjusting    and    the    implementation   should   be    modified 
for    tighter   controls   en  the    system  console   operator's 
ability    to    override    the   system   default   urgencies.       Also, 
enhancements  to    prohibit    application    software   from    reaching 
urgencies   in  the    WIN    software    level   is   necessary.      This 
would    discourage   resource  competition    and   improve    system 
slowdown.      One    urgency  system   recommended    included    net 
allowing    any  application    software  to    exceed   an   urgency    cf 
10.       Few    users,    mostly  system   programmers,    would    operate    a*, 
urgencies   cf  30    to    40   and  no   users   would    exceed    40.      This 
proposal    leaves    urgencies  of    40    to  63   for   system    software 
and    WIN    software. 

A   new   TSS   Monitor   has    been    developed    within    the    WWMCCS 
community.      This    monitoring    software    is    easy   to    use    via 
system    console    commands    and    no    system    interruption    is    exper- 
ienced.     Onf crtunately,    this  new    Monitor    was   not    operational 
for    IVY    LEAGUE    82;    but  it   can    be    utilized    during    the    next 
exercise    for   selected   small    periods    of    time    to   allow   a    mere 
thorough    analysis   of    slowdown    periods.      [Hef.    22:    p.    4-4] 
With    the    WIS  modernization    plan,    the    capability    to    monitor 
each    network   element    is   achieved    through   the    Monitoring 
Canters    cf    the    DDN.       DDN    will   also  provide    an   automatic 
fault    recognition   and   isolation    for    trouble    spots    with    most 
reconfigurations   being  handled    without   dedicated    personnel. 
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WIN   software,    such  as  the  memory    management    algorithms 
for    PIS    and    TELNET,    should    be    redesigned   to   reduce    the    allo- 
cation   and    deallocation   processing  for    memory.      One 
alternative    could   be   a   minimum   size    of   memory  allowed    for 
allocation,    this   would   eliminate   the    overhead   generated    in 
the    swapping  of    1K. 

Additionally,  improved  operational  procedures  are  needed 
concerning  teleccnf erencing  transcript  files.  Options  avai- 
lable   include: 

(1)  spooling   the    printed   output    with    a  lower   urgency 
which   would    force  printing  at    less    critical    times 

(2)  allowing    printing  of   the    transcript    file 
reguests   only   during  scheduled   time    periods 

The    rescurce   contention    problem,    especially    at    the    NMCC, 
is   stated   as  a    top    priority    of   the   WIS    modernization    plan; 
however,    no    tangible    alternatives   have    been   proposed. 

F.       JDS    BESCDBCB   CONTENTION 

The    memory    chasing   problems    of   the    JDSIP   and    JDSUP 
subsystems    may    be   approached    from    several    alternatives. 
Obviously,    the    aiount   of   allocation/deallocation    depends 
almost    entirely    on    the  idle-time    of    the    subsystem.       Studies 
should   be    conducted    at   each    site   supporting  the    Remcte 
User's   Package     (RU?)     to   determine   its    use/idle  ratio.       If 
the    JDSIF    subsystem    remains    in    memory    the    majority    cf   the 
time,    Jtininum   overhead  is  generated.       If    the    JDSIP   use/idle 
ratio    is    small,    significant    overhead    will    be    generated    by 
the    subsystem  changing  urgencies  to    engage   placement    in   cere 
and    the    chance    of   checking    for    transaction    activities.       &n 
alternative    would    be   the    development    dl    a   small    check- 
routine    to    permanently  reside    in    primary    memory.       Its    job 
would   be   to    periodically,   every   two   to   three   seconds,    check 
for    mcciing  transactions   and   change    the   JDSIP   urgency    to   51 
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if   transactions    are    available   for   processing,    at    the    sarre 
time    changing   its   owr    urgency   to    zero.      This    would    produce   a 
sleep   state   similar   to  -chat    of   the  JDSIP    when   inactive,    only 
the    check-routine    would    not    leave   core.       When   the    JDSIP 
finished   the  necessry   transaction   processing,    it    wculd 
decrease   its  urgency   to   zero   and   change   the   check-routine 
urgency    tc    51.       This    would    allow    the    JDSIP   to    be    swapped  to 
mass    storage  at    the    next    memory    request    and   the   check- 
routine    wculd  have    high    priority   for    processor   time    and 
resume    waiting    for   the  next    transaction. 

Another   alternative   to    be   considered    is  the    permanent 
allocation    cf   288   to    the   JDSIP.      This    would   allow    the   JDSIP 
permanent    residence    in   primary   memory   and   is    feasible    if   the 
host    system    is   not    memory-restricted. 

The    JESUS  subsystem   remains    in   primary    memory    itself    at 
9K    but    periodically    requires   an   addition   50K    for    processing. 
Part    cf    the    problem    concerning  the  JDSUP   memory    allocation 
stems    frcn    the    J?SUP    requiring   one  single    block   of    5CK    cf 
Doemory.      Generally,    the    system   must    rearrange   memory    tc 
create   a   contiguous    50K    block.      The   easiest    solution    wculd 
te   the    permanent  attachment    of    -he   5  OK   to   the    JDSUP 
subsystem.      For    2   system    memory-restricted   at    all,    this 
alternative    is    i  upra  ctical.       A    more    feasible   alternative- 
would    be    to    include    50K    in    the   system   size    for  the   JDSUP    and 
treat    the    59K  as   one    system.      Then   modify    the   JDSUP    to 
reside    en   mass    stoarge  and    utilize   a    check -routine,    similar 
to   the    JESIF,    for   dynamic  checking  cf    requirements.      The 
same    urgency   swapping  and   processing    schemes    could    be 
utilized. 

In    addition    to    the   specific    modifications   to    the    JES 
subsystem,    several    other    measures    could    be   taken    tc    improve 
WIN    rescurce  requirements: 

(1)     development    cf    standards    for   new   application 
software 
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(2)  standard    criteria    for   resource   requirements   in 
new    software 

(3)  code   optimization   and   memory    overlays    fcr    larger 
systems 

(4)  utilization   of    data    compression   techniques 

(5)  imprcved    input/output  interfaces 

(6)  more   efficient    data   transaction   activites 

(7)  elimination  of    large    data   transfers 

G.       CONCLUSIONS 

Cne    of   the    largest   problems    with    the    Defense    Data 
Network     (DDN)    will    be   the   Multi-Level    Security  issue.       With 
the    variety  of    users    linked    through   ens    common   network,    a 
RLS    system    will    be    imperative. 

Another   DDN    concern    is    the    standard    data    communications 
protocol.-:.      These    protocols    should  not    only    interface    with 
the    WSMCCS    sites,    but   should    be    able    to    interact    with    NATO 
systems    ::or   greater    interoperability.      The    Wis   J?M    presently 
intends    to    require    standard    protocols    be    written    in    the    new 
EOD    d€sigr.    language,    ADA.       While    no    ADA    compiler   has    been 
fully    certified    as    meeting    all   DOD  standards,    the    step 
towards    standard   software  should    begin   at    software 
cene  spticn. 

The    WIS    modernization   plan    will    bring    modern    software 
and    later    hardware    into   the    WWMCCS   community.      The    Wis    JPM 
strategy   is    to    tackle   the  softwara   problems    in    wWMCCS    first 
and    bypass    the    fast    icving    tachnology    field   of   hardware 
until    later.      Not   all  of    the    WWMCC3    standard    software    needs 
rewriting   and   by    modernizing    the    software    first,    the    WWMCCS 
network    will  become    more    adept    to   present    day    requirements. 

WWMCCS    HEP    problems    will   not    be   solved    by    the    WIS    moder- 
nization   plan   or   hardware  changes  alone.       The    WWMCCS 
computer    systems   ara    used   for   war-gaming    and    software 
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development    but    the    primary    intention   of   this  C3    system 
surfaces    during    crises  with    the    handling   of   message    traffic. 
The    heart    of  the    WWMCCS    ADP    program    must    be   a    fast,    reliable 
and    secure   transaction  processing  system.      Faster    routing 
algorithms    irust    be    developed   and   improved   physical    surviv- 
ability   is   critical.      Now,    every    node   on   the   WWMCCS    network 
is   vulnerable  to  easy   destruction  and   each   node   lost    has    a 
great   impact  on    total  system   performance. 

The    WIS    modernization   plan    with   an   improved    DBMS, 
management    and    security    procedures,    and   user    interface    is  a 
significant    start   towards  the   remodeling   of    WWMCCS.      The 
modernization   is   planned  over   a   ten    year   period   and   a    major 
concern    will  be    maintaining    service    dollar    support. 

The    Joint   Deployment    System    will    certainly   benefit    frcm 
the    WIS    modernization   plan.       But   the    areas    of   network 
management,    multi-level    security,    and    resource  contention 
must    be    addressed    by   the    modernization    plan   and    alternatives 
proposed.      In  the    meantime,    the    Joint    Deployment    Agency    will 
continue   to    develop    JCS-unique   software   to   supplement    WWMCCS 
capabilities  and    provide   deployment    information    through 
crisis   situations. 
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